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

analysis

Browse source
This commit is contained in:
Joey Hess 2020-10-23 13:00:55 -04:00
parent 0736383e98
commit cb6cf20b9a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 26 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/bugs/storeKey_when_already_present_failures_on_Windows/comment_1_7e089c436af03ffd8ad00dba45156a14._comment Normal file
View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2020-10-23T16:50:31Z"
content="""
So this is the testremote of the directory special remote, and the failing
test tries to store content into the remote which already contains that
content, an unusual edge case since git-annex normally knows when a remote
has content and avoids resending it.
Remote.Directory.finalizeStoreGeneric removes the old directory, and moves
the new one into place. This is not the first time I've seen windows fail
in such a situation, it seems that directory removals are not atomic, or
don't really fully finish by the time the call returns, or something else
like antivirus has a file open in the directory and so prevents deletion.
Or something like that.
This kind of thing is why I am not enthused about wasting any more time
on supporting Windows. `rm -rf foo && mv bar foo` should not cause a bug report
that requires me to dig out a VM and put in complex and expensive
workarounds. The tar pit has no bottom.
(Also, FWIW, git-annex test on the jenkins autobuilder always exploded from
the very beginning, so was always || true, which is why the windows install
page encourages windows users to test git-annex themselves.)
"""]]