Please describe the problem.
Now we have github action which builds git-annex with libmagic support. Unfortunately we had to "allow" git annex test
to fail to proceed for now. Although it looks not that bad -- there is only one "test" which fails in various scenarios (to the total of 12 out of 704 tests failed (616.78s)
)
2020-10-22T18:50:07.2946875Z storeKey when already present: FAIL (0.02s)
2020-10-22T18:50:07.2948174Z .\Command\TestRemote.hs:290:
2020-10-22T18:50:07.2949772Z failed
full log copy link to original workflow run
When I ran annex test
after installing that installer in a local Win 10 VM, I have got a lesser count (8 out of 704 tests failed (1197.82s)
) full log
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.)
I've made it display whatever exception caused the test to fail, which should help pin down a bit more what the problem is.
Turns out Remote.Directory was using removeDirGeneric everywhere it needed to remove a directory, except for in what I believe is failing here. And removeDirGeneric already has a workaround for some windows quirk in it.
So I changed that to use it too. I don't know if that will fix the problem.
All 704 tests passed (698.50s)
!!! so it might have fixed it. I will submit a PR removing|| true
to see if that sticks, and also will test locally