115 lines
5.1 KiB
Markdown
115 lines
5.1 KiB
Markdown
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.
|
|
|
|
* 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]]
|