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

Windows: Work around win32 length limits when dealing with lock files

Browse source
This commit is contained in:
Joey Hess 2021-01-13 14:38:35 -04:00
parent bb4dc3a399
commit 5e39b7eb8d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 69 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

33
doc/bugs/Windows__58___drop_claims_that___34__content_is_locked__34__/comment_2_00fa93b8a064bd1e6ca6c35b1a10d5aa._comment Normal file
View file

@ -0,0 +1,33 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2021-01-13T17:25:08Z"
content="""
It seems that Utility.LockFile.Windows.openLock
must be returning Nothing for this message
to be displayed.
Which it does when CreateFile returns `INVALID_HANDLE_VALUE`. Which
it makes sense it would do for a filename that's too long. Except
that's taken to mean the locking failed due to it being locked.
(So it seems createfile with the too-long filename is creating the file but
then failing that way. Which is weird.)
It might be possible to use windows's `GetLastError` to find out that it
failed due to length, but the API docs don't seem
to say what the error value is in that case.
Normally ghc modifies filenames on windows to not use the
compatability layer that has this filename length limit. But since
this is using the low-level CreateFile, that does not happen here.
The code that does that is not exposed (`create_device_name` in base's
cbits/fs.c)
It's basically a matter of prepending `\\?\` to the path, but it also
has to be made absolute and cannot contain '/'.
I've implemented something similar in git-annex, which I hope will solve
this. I have not tried it on windows yet so leaving the bug open for
confirmation.
"""]]