git-annex/Annex/Content
Joey Hess 478ed28f98
revert windows-specific locking changes that broke tests
This reverts windows-specific parts of 5a98f2d509
There were no code paths in common between windows and unix, so this
will return Windows to the old behavior.

The problem that the commit talks about has to do with multiple different
locations where git-annex can store annex object files, but that is not
too relevant to Windows anyway, because on windows the filesystem is always
treated as criplled and/or symlinks are not supported, so it will only
use one object location. It would need to be using a repo populated
in another OS to have the other object location in use probably.
Then a drop and get could possibly lead to a dangling lock file.

And, I was not able to actually reproduce that situation happening
before making that commit, even when I forced a race. So making these
changes on windows was just begging trouble..

I suspect that the change that caused the reversion is in
Annex/Content/Presence.hs. It checks if the content file exists,
and then called modifyContentDirWhenExists, which seems like it would
not fail, but if something deleted the content file at that point,
that call would fail. Which would result in an exception being thrown,
which should not normally happen from a call to inAnnexSafe. That was a
windows-specific change; the unix side did not have an equivilant
change.

Sponsored-by: Dartmouth College's Datalad project
2022-05-23 13:21:26 -04:00
..
Presence split verifyKeyContent 2021-07-29 13:58:40 -04:00
LowLevel.hs finish fixing removeLink on windows 2020-11-24 13:20:44 -04:00
PointerFile.hs avoid warning when built with unix-compat 0.5.3 2021-10-18 16:25:28 -04:00
Presence.hs revert windows-specific locking changes that broke tests 2022-05-23 13:21:26 -04:00