summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2015-01-20 17:35:48 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2015-01-20 17:35:48 -0400
commit745525e80bb6915f3eb63554de9b735b75991f7d (patch)
tree1e3de87028105902b20b1e232807b2348d78fefe
parent91db5dfb006070a4875da133db8e8e386416c16e (diff)
devblog
-rw-r--r--doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn30
1 files changed, 30 insertions, 0 deletions
diff --git a/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn
new file mode 100644
index 000000000..59865b36b
--- /dev/null
+++ b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn
@@ -0,0 +1,30 @@
+Today I got The pre-commit-annex hook working on Windows. It turns out that
+msysgit runs hook scripts even when they're not executable, and it parses
+the #! line itself. Now git-annex does too, on Windows.
+
+Also, added a new chapter to the walkthrough,
+[[walkthrough/using_special_remotes]]. They clearly needed to be mentioned,
+especially to show the workflow of running initremote in one repository,
+then syncing another repository and running enableremote to enable the same
+special remote there.
+
+Then more fun Windows porting! Turns out git-annex on Windows didn't handle
+files > 2 gb correctly; the way it was getting file size
+[uses a too small data type on Windows](https://github.com/jystic/unix-compat/issues/16).
+Luckily git-annex itself treats all file sizes as unbounded Integers,
+so I was easily able to swap in a `getFileSize` that returns correct
+values for large files.
+
+While I haven't blogged since the 13th and have not been too active until
+today, there are still a number of little improvements that have been done
+here and there.
+
+Including a fix for an interesting bug where the assistant would tell
+the remotedaemon that the network connection has been lost, twice in a row,
+and this would make the remotedeamon fail to reconnect to the remote when
+the network came up. I'm not sure what situation triggers this bug (Maybe
+machines with 2 interfaces? Or maybe a double disconnection event for 1
+interface?), but I was able to reproduce it by sending messages to the
+remotedaemon, and so fixed it.
+
+Backlog is down to 118 messages.