]> dgit.raspbian.org Git - git-annex.git/commit
delete content lock file safely on drop, keep after shared lock
authorJoey Hess <joeyh@joeyh.name>
Thu, 13 Jan 2022 17:58:58 +0000 (13:58 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 13 Jan 2022 17:58:58 +0000 (13:58 -0400)
commita3b6b3499b07228403a47d2bc0e325e511b99062
tree16a1a46ecc3233192729c2b331f8e02d9281a861
parent3d7933f12470ad6d62704a9569f447f66492d481
delete content lock file safely on drop, keep after shared lock

This seems to be the best that can be done to avoid forever accumulating
the new content lock files, while being fully safe.

This is fixing code paths that have lingered unused since direct mode!
And direct mode seems to have been buggy in this area, since the content
lock file was deleted on unlock. But with a shared lock, there could be
another process that also had the lock file locked, and deleting it
invalidates that lock.

So, the lock file cannot be deleted after a shared lock. At least, not
wihout taking an exclusive lock first.. which I have not pursued yet but may.

After an exclusive lock, the lock file can be deleted. But there is
still a potential race, where the exclusive lock is held, and another
process gets the file open, just as the exclusive lock is dropped and
the lock file is deleted. That other process would be left with a file
handle it can take a shared lock of, but with no effect since the file
is deleted. Annex.Transfer also deletes lock files, and deals with this
same problem by using checkSaneLock, which is how I've dealt with it
here.

Sponsored-by: Dartmouth College's Datalad project
Annex/Content.hs