use replaceWorkTreeFile when fixing an annex symlink

This does not change any behavior, but it's useful for all worktree
changes to be made using this.

Sponsored-by: Graham Spencer on Patreon
This commit is contained in:
Joey Hess 2022-06-22 13:40:14 -04:00
parent cfc65ee9fc
commit af1a45c69c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 6 additions and 7 deletions

View file

@ -97,11 +97,11 @@ fixSymlink file link = do
mtime <- liftIO $ catchMaybeIO $ Posix.modificationTimeHiRes
<$> R.getSymbolicLinkStatus file
#endif
createWorkTreeDirectory (parentDir file)
liftIO $ R.removeLink file
liftIO $ R.createSymbolicLink link file
replaceWorkTreeFile (fromRawFilePath file) $ \tmpfile -> do
let tmpfile' = toRawFilePath tmpfile
liftIO $ R.createSymbolicLink link tmpfile'
#if ! defined(mingw32_HOST_OS)
liftIO $ maybe noop (\t -> touch file t False) mtime
liftIO $ maybe noop (\t -> touch tmpfile' t False) mtime
#endif
stageSymlink file =<< hashSymlink link
next $ return True

View file

@ -4,9 +4,8 @@ file, and then they call that to replace it with something else. But in
between, the file could be overwritten with other content. And that content
then gets replaced, which is not expected behavior.
Some other commands may modify the worktree without using it (oops)
and also be susceptable to a race. `git-annex fix` in fixSymlink, for example,
checks if the file is a symlink, and then deletes and recreates it.
(Some other commands may modify the worktree without using it (oops)
and also be susceptable to a race?)
[[!commit 5ef79125ad0eddd5467b6bec451fdcdbd748b96f]] fixed one of these
races, but not in an ideal way.