Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
1b79f2404d
9 changed files with 158 additions and 0 deletions
|
|
@ -0,0 +1,21 @@
|
|||
[[!comment format=mdwn
|
||||
username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
|
||||
nickname="asakurareiko"
|
||||
avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
|
||||
subject="comment 11"
|
||||
date="2021-10-06T21:10:34Z"
|
||||
content="""
|
||||
I'm still experiencing this bug with 8.20200226. If the repo is cloned by ssh before doing `git annex init`, then the result is:
|
||||
|
||||
```
|
||||
Unable to parse git config from origin
|
||||
|
||||
Remote origin does not have git-annex installed; setting annex-ignore
|
||||
```
|
||||
|
||||
|
||||
Creating an empty repo and doing `git annex init` first then adding the remote and pulling in changes works fine, but this creates unrelated history on the `git-annex` branch.
|
||||
|
||||
|
||||
This affects ssh remotes but not local remotes.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
|
||||
nickname="asakurareiko"
|
||||
avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
|
||||
subject="comment 12"
|
||||
date="2021-10-07T06:21:25Z"
|
||||
content="""
|
||||
The problem I had was actually specific to WSL1. I added a section in [[todo/windows_support]] about cloning a repo with ssh in WSL1.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="alex@f04d0d3c452a2a99b27ccc93c1543bee4a1bf5be"
|
||||
nickname="alex"
|
||||
avatar="http://cdn.libravatar.org/avatar/9d97e9bcb1cf7680309e37cd69fab408"
|
||||
subject="Re: Resuming an interrupted download"
|
||||
date="2021-10-08T03:06:57Z"
|
||||
content="""
|
||||
Thanks, that works great!
|
||||
"""]]
|
||||
|
|
@ -130,3 +130,38 @@ Seems like this would need Windows 10.
|
|||
|
||||
> > > > But here's a bug about sqlite in WSL:
|
||||
> > > > [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]] --[[Joey]]
|
||||
|
||||
## Update Oct 2021: Steps for using git-annex on NTFS with WSL1 (an experimental setup for those adventurous enough)
|
||||
|
||||
The following steps are tested on Windows 10 21h1 with Ubuntu 18.04/20.04 and are specifically designed to work around these two bugs:
|
||||
|
||||
* [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]]
|
||||
* [[bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem]]
|
||||
|
||||
Do the following:
|
||||
|
||||
1. Enable Developer mode in Windows settings so that symlinks can be created without elevated privileges.
|
||||
2. Mount the NTFS drive with metadata option. This line can be added in `/etc/fstab`: `C: /mnt/c drvfs metadata`. I prefer to also add `uid=1000,gid=1000,fmask=0133,dmask=0022`.
|
||||
3. Create an empty directory where your repo will be. Then enable case sensitivity `setfattr -n system.wsl_case_sensitive -v 1 <path>`. This attribute will be automatically and recursively applied to any future subdirectories. If setfattr(1) errs out with permission denied, you can also effect the same change in CMD.EXE / Windows Powershell as admin with `fsutil file setCaseSensitiveInfo <path> enable`.[^1] You can check that the setting is enabled with `getfattr -n system.wsl_case_sensitive <path>` under WSL1.
|
||||
4. Create the repo however you like (see steps below for cloning a repo with ssh). Immediately after `git annex init`, do `git config annex.crippledfilesystem true`. If you set `crippledfilesystem` before init, then git annex will try to enter an adjusted branch and trigger the first bug. If you do not set `crippledfilesystem` after init, you will trigger the second bug when doing `git annex add`.
|
||||
|
||||
[^1]: This works because Administrators usually have Full Control over most files. What Windows actually looks for is "Write attributes", "Create files", "Create folders" and "Delete subfolders and files" permissions on the directory required for changing case-sensitivity. As a regular user (or without UAC) you might not have those permissions by default for instance on external drives, so adjust accordingly. For more info about about the `system.wsl_case_sensitive` attribute see this blog post: [[https://devblogs.microsoft.com/commandline/improved-per-directory-case-sensitivity-support-in-wsl/]]
|
||||
|
||||
### Cloning a repo with ssh
|
||||
|
||||
When cloning a repo with ssh, `git annex init` will fail to enable ssh remotes if `crippledfilesystem` is not set, but you also cannot set it before init. Follow these steps to avoid unrelated history in the `git-annex` branch.
|
||||
|
||||
git clone <sshpath> annex
|
||||
cd annex
|
||||
git branch git-annex origin/git-annex
|
||||
git remote remove origin
|
||||
git annex init
|
||||
git config annex.crippledfilesystem true
|
||||
git remote add origin <sshpath>
|
||||
git annex sync
|
||||
|
||||
### Using symlinks and locked files
|
||||
|
||||
* You can now use symlinks and locked files but please remember that locked files can still be overwritten. So make sure to unlock them before you edit them.
|
||||
* After you `git annex get` files, the symlinks for those files will still be broken. Recreate the symlinks to fix them. You can make a script or delete them and `git checkout`.
|
||||
* It can be difficult to use symlinks on Windows because programs will see the link target rather than the link, which makes it impossible to do things like navigating between files in the same directory or using opened file history. You can unlock the files or access them through another filesystem layer such as SMB.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
[[!comment format=mdwn
|
||||
username="jkniiv"
|
||||
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
|
||||
subject="the WSL1 use case"
|
||||
date="2021-10-07T04:12:48Z"
|
||||
content="""
|
||||
User asakurareiko added some instructions to this page how to use git-annex in Ubuntu 20 (presumably
|
||||
20.04) in WSL1 and I tested them out in my older Ubuntu 18.04 installation and found out that they
|
||||
amazingly work although my Windows apps couldn't access any of the files that were still locked.
|
||||
Somehow the symlinks were only in a form that only WSL1 and Cygwin/MSYS2/Git Bash could access
|
||||
(mind you I have developer mode active and my Windows 10 is also version 21H1 so the environment
|
||||
was otherwise similar). An interesting use case nonetheless. I edited the section with my corrections
|
||||
-- I hope asakurareiko doesn't mind. :)
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
[[!comment format=mdwn
|
||||
username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
|
||||
nickname="asakurareiko"
|
||||
avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
|
||||
subject="comment 22"
|
||||
date="2021-10-07T06:17:30Z"
|
||||
content="""
|
||||
For me I tried git on windows at first but when checking out the working tree after a clone it slowed down so much that it would not complete in a reasonable amount of time. So that's why I decided to try using WSL1.
|
||||
|
||||
In my opinion it's not necessary to use `case=dir`. `case=dir` was at one point the default but was removed as the default due to the potential to cause problems with windows programs ([[https://devblogs.microsoft.com/commandline/improved-per-directory-case-sensitivity-support-in-wsl]]). But if you do have `case=dir` then it is not necessary to set the attribute.
|
||||
|
||||
If your symlinks are not working, make sure to have deleted and recreated the symlinks after doing `git annex get` and that the NT symlink requirements listed [here](https://github.com/MicrosoftDocs/WSL/releases/tag/17046) have been met. If the symlink target has changed from file to directory or vice versa the symlink also has to be recreated. However there are other reports of symlinks not working despite following these requirements:
|
||||
|
||||
* [[https://github.com/microsoft/WSL/issues/353#issuecomment-544857020]] Commenter is using Windows 10 Home 1903. (I'm using Windows 10 Enterprise)
|
||||
* [[https://github.com/microsoft/WSL/issues/353#issuecomment-478953190]] Commenter updated to Windows 10 1809 and it stopped working.
|
||||
* [[https://github.com/microsoft/WSL/issues/353#issuecomment-478048780]] Commenter mounted with UNC rather than drive letter.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
[[!comment format=mdwn
|
||||
username="jkniiv"
|
||||
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
|
||||
subject="comment 23"
|
||||
date="2021-10-07T11:36:48Z"
|
||||
content="""
|
||||
@asakurareiko: Oh, based on [[https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity#case-sensitivity-options-for-mounting-a-drive-in-wsl-configuration-file]]
|
||||
I got the impression that `case=dir` was a prerequisite to make the attribute `system.wsl_case_sensitive`
|
||||
work as per the heading \"Default setting: dir for enabling case sensitivity per directory\". I guess
|
||||
I was wrong, `case=off` works too. I'll remove `case=dir` it from the instructions once again.
|
||||
|
||||
Also the NT symlink requirements are fulfilled in my case simply by way of me having developer mode
|
||||
enabled in 21H1 (Windows 10 Pro). I create symlinks all the time with
|
||||
\"cmd /c mklink ...\" in Powershell without elevation. Git-annex also creates only relative symlinks
|
||||
which was also a requirement in the WSL release news you mentioned. No, this must be one of those
|
||||
miscellanous problems mentioned in [[WSL issue 353|https://github.com/microsoft/WSL/issues/353]].
|
||||
|
||||
_Edit_: Oh, in fact recreating the symlink after getting the file with `git-annex get` by deleting the symlink
|
||||
with rm and then checking it out again with `git checkout -- <file>` seems to allow me to access
|
||||
the file in Windows just fine. Interesting. Maybe it's git-annex itself that creates the wrong
|
||||
kind of symlink that a later call to plain git can repair. Quite convoluted it seems.
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
[[!comment format=mdwn
|
||||
username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
|
||||
nickname="asakurareiko"
|
||||
avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
|
||||
subject="comment 24"
|
||||
date="2021-10-07T16:27:39Z"
|
||||
content="""
|
||||
One of the requirements in particular is that the link target must exist. In a freshly cloned repo the link targets do not exist so it's important to recreate the symlinks after you get the annexed files.
|
||||
|
||||
NT symlinks must have either file or directory target type. If the link target does not exist at the time when the symlink is created, it's not possible to determine the target type.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
[[!comment format=mdwn
|
||||
username="jkniiv"
|
||||
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
|
||||
subject="comment 25"
|
||||
date="2021-10-07T18:27:19Z"
|
||||
content="""
|
||||
> _asakurareiko_: One of the requirements in particular is that the link target must exist. ...
|
||||
|
||||
That's useful info. :) Many thanks for your input regarding WSL1 use! For me that opens up new avenues by way of
|
||||
borg special remotes (borg support on Windows is very lacking and there are no recent binaries for it).
|
||||
I still think git -- and to a lesser extent git-annex -- is performant enough on native Windows, so I'm
|
||||
going to continue using it that way for those repos that need to be foolproof and in a supported configuration.
|
||||
But for more experimental uses WSL1 still holds quite some promise wrt git-annex. DrvFs is still many times faster
|
||||
than 9p of WSL2 *for Windows native files on NTFS* which is an important use case for exchanging data between
|
||||
Windows and POSIXland. In fact while WSL2 boots incredibly fast for a Hyper-V virtual machine, in many file-level
|
||||
use cases it can't hold candle to the almost seamless nature of WSL1. The latter has its warts in API compatibility
|
||||
but in my mind it's quite a undervalued little performer. I hope Microsoft doesn't remove it too soon in favor of WSL2.
|
||||
"""]]
|
||||
Loading…
Add table
Reference in a new issue