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

avoid unix-compat's rename

Browse source 
On Windows, that does not support long paths
https://github.com/jacobstanley/unix-compat/issues/56

Instead, use System.Directory.renamePath, which does support long paths.

Sponsored-by: Dartmouth College's Datalad project
This commit is contained in:
Joey Hess 2022-07-12 14:53:32 -04:00
parent bad39cadc6
commit 2d65c4ff1d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
18 changed files with 75 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/testremote_is_not_honoring_--backend.mdwn
View file

@ -33,3 +33,5 @@ CI used
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
All the time! Sorry to mostly show up when there is an issue!
[[!tag projects/datalad]]

24
doc/bugs/testremote_is_not_honoring_--backend/comment_2_f804c33243606cab4495238511e59743._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2022-07-12T16:50:16Z"
content="""
Actually testremote will not accept --backend in current master, since that
is no longer a global option and is accepted only by commands that can
actually use it.
testremote cannot support an arbitrary backend here, because it needs to
generate a test key that cannot possibly be used for real data. The only
backend that has a way implemented to do that is SHA256. It would not,
for example, be possible to make the WORM backend support that, since every
possible WORM key could be used by real data.
It would be possible to add support for --backend=MD5 and have it reject
other backends. But this does not strike me as solving the real problem.
Also, in [[bugs/tests_fail_on_windows__58___retrieveKeyFile_resume]]
I ran into this same problem, when `git-annex test` was ran, and
worked around it by disabling that part of the test suite on windows.
If this is fixed, it would be worth re-enabling that, although it may have
also been failing for other reasons on windows.
"""]]

24
doc/bugs/testremote_is_not_honoring_--backend/comment_3_1261222f79d9dbc8cf92f6466361e113._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2022-07-12T17:42:51Z"
content="""
ghc's IO manager tries to support Windows long paths by normalizing to
an UNC-style path in many system calls. However, when git-annex calls
rename, on windows that ends up in Win32's moveFileEx (via unix-compat),
and that does not do UNC-style normalization. And given the description of
the Win32 package, I think it's intended to pass data directly through
to the API without anything fancy.
System.Directory.renamePath could be used instead of Win32.
While it still uses Win32 moveFileEx, it first does an UNC-style
normalization. Filed an issue:
<https://github.com/jacobstanley/unix-compat/issues/56>
Rather than waiting for that to be fixed, I've made git-annex
use System.Directory.renamePath instead itself. But I don't know
if it will be enough to make testremote work, or if it will fall over
on a later operation on the same too-long path.
getFileStatus/getSymbolicLinkStatus seem like the main things in
unix-compat that would still be a problem.
"""]]