136 lines
5.7 KiB
Markdown
136 lines
5.7 KiB
Markdown
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
|
|
|
|
[[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.
|
|
|
|
> 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:
|
|
> > > > [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]] --[[Joey]]
|
|
|
|
## update Sept 2022:
|
|
|
|
Git-annex has become more reliable on WSL1 recently, see [[tips/Using_git-annex_on_NTFS_with_WSL1]].
|