86 lines
3.6 KiB
Markdown
86 lines
3.6 KiB
Markdown
The git-annex Windows port is beta, but rapidly becoming polished and
|
|
usable!
|
|
|
|
## 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.
|
|
|
|
## 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?
|
|
|