mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
jkniiv 2021-10-07 11:36:49 +00:00 • committed by admin
parent 392a886263
commit d9c2a632f5
1 changed files with 23 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

23
doc/todo/windows_support/comment_23_616a7d579730e5a4f5cc314d6328bfd0._comment Normal file
View file

@ -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.
"""]]