git-annex/doc/todo/windows_support.mdwn

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


## status

* There can be problems when the git-annex repository is in a deep
  or long path. Ie, `C:\loooooooooooooooooongdir\`.
  [Details here](http://git-annex.branchable.com/bugs/__34__git-annex:_direct:_1_failed__34___on_Windows)

  Workaround: Put your git-annex repo in `C:\annex` or some similar short
  path if possible.

  Workaround: Enable long paths in the registry. See 
  <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247#maxpath>

* 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

[[bugs/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.

* `md5FilePath` still uses the filesystem encoding, and so may produce the
  wrong value on Windows. This would impact keys that contain problem characters
  (probably coming from the filename extension), and might cause
  interoperability problems when git-annex generates the hash directories of a
  remote, for example a rsync remote.

* `encodeW8` is used in Git.UnionMerge, and while I fixed the other calls to
  encodeW8, which all involved ByteStrings reading from git and so can just
  treat it as utf-8 on Windows (via `decodeBS`), in the union merge case,
  the ByteString has no defined encoding. It may have been written on Unix
  and contain keys with invalid unicode in them. On windows, the union
  merge code should probably check if it's valid utf-8, and if not,
  abort the merge.

* 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/>
> 
> 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]]