The git-annex Windows port is beta, but rapidly becoming polished and usable!

status

  • Local pairing seems to fail, after acking on Linux box, it stalls. (Also, of course, the Windows box is unlikely to have a ssh server, so only pairing with a !Windows box will work.)

  • gcrypt is not ported to windows (and as a shell script, may need to be rewritten)

  • Deleting a git repository from inside the webapp fails "RemoveDirectory permision denied ... file is being used by another process"

  • Tor remotes are not supported yet. Should not be very hard to get it working.

potential encoding problems

?Unicode file names ignored on Windows is fixed, but some potential problems remain, since the FileSystemEncoding that git-annex relies on seems unreliable/broken on Windows.

  • When git-annex displays a filename that it's acting on, there can be mojibake on Windows. For example, "háčky.txt" displays the accented characters as instead the pairs of bytes making up the utf-8. Tried doing various things to the stdout handle to avoid this, but only ended up with encoding crashes, or worse mojibake than this.

    This may be use to windows actually using utf-16, but git-annex uses utf-8 for filename encoding when on windows.

  • If interoperating with a git-annex repository from a unix system, it's possible for a key to contain some invalid utf-8, which means its filename cannot even be represented on Windows, so who knows what will happen in that case -- probably it will fail in some way when adding the object file to the Windows repo.

  • If data from the git repo does not have a unicode encoding, it will be mangled in various places on Windows, which can lead to undefined behavior.

minor problems

  • webapp lets user choose to encrypt repo, and generate gpg key, before checking that gcrypt is not installed
  • Ssh connection caching does not work on Windows, so git annex get has to connect twice to the remote system over ssh per file, which is much slower than on systems supporting connection caching.
  • glacier-cli is not easily available (probably)

stuff needing testing

  • test that adding a repo on a removable drive works; that git is synced to it and files can be transferred to it and back
  • Does stopping in progress transfers work in the webapp?

do we need this port anymore?

See http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html

If windows has transparent support for running linux executables, and those executables can access files in "." which are on the windows system, then you could just use this to run linux git-annex on windows. No port needed.

That would be great!

Seems like this would need Windows 10.

The latest builds of Windows 10 (build 15063) can run git-annex in the Windows Subsystem for Linux. After following the instructions at https://msdn.microsoft.com/en-us/commandline/wsl/about, run: sudo apt-get install git-annex

git-annex in WSL passes its full test suite, and it avoids all the problems discussed in sections above.

git-annex can access Windows files in eg /mnt/c, so a git-annex repository can be stored there. However, if the git-annex repository uses indirect mode, the symlinks used by git-annex won't be usable by Windows programs. Use either direct mode, or v6 mode to avoid the symlink problem.

Also, see this important caveat: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

March 2017: WSL is currently rather annoying to enable. If it became easy enough to enable, note that "bash -c git-annex" works from a windows command prompt, and would probably work in a .bat file as well, so git-annex from the WSL could be transparently used on the windows side.

The webapp does not currently work. It doesn't know how to open a web browser from the linux side. There are also what look like some emulation problems around the daemonization code. git annex assistant --foreground does run, but while it notices when new files are added, it does not notice when existing files get modified. Probably an inotify emulation bug. --Joey

Update May 2018: With the latest MS Edge VirtualBox image, enabling WSL was much easier than before, just a matter of checking a single box and a reboot. No need to enable developer mode first. (Don't know if this will apply to commercial Windows 10 or only this VM image.)

Then bash was available in the menu, but it said no distro installed, and gave an url to a "Store" where Ubuntu, Debian, etc could be installed.

git-annex test had a failure this time, something to do with disk IO error and sqlite.

The assistant can run as a daemon now. It still doesn't notice some changes. Eg with "rm foo; echo new > foo", it got an inotify event for the removal, but missed the new creation.

Running git annex assistant when the assistant is running complains of a stale pid file, with the wrong pid number, but it doesn't start a second one.

webapp still can't open a web browser, but there's a way to do it from within WSL that it should be possible for it to use: powershell.exe Start http://google.com ("powershell.exe" is in PATH)

--Joey

The sqlite problem may be fixed in git-annex 7. I fixed some similar, less frequent crashes on Linux. Need to test on windows. --Joey

But here's a bug about sqlite in WSL: WSL adjusted braches: smudge fails with sqlite thread crashed - locking protocol --Joey

update Sept 2022:

Git-annex has become more reliable on WSL1 recently, see Using git-annex on NTFS with WSL1.