fix potential race in updating inode cache
Some uses of linkFromAnnex are inside replaceWorkTreeFile, which was already safe, but others use it directly on the work tree file, which was race-prone. Eg, if the work tree file was first removed, then linkFromAnnex called to populate it, the user could have re-written it in the interim. This came to light during an audit of all calls of addInodeCaches, looking for such races. All the other uses of it seem ok. Sponsored-by: Brett Eisenberg on Patreon
This commit is contained in:
parent
e4b2a067e0
commit
14683da9eb
5 changed files with 22 additions and 6 deletions
|
@ -85,7 +85,7 @@ makeHardLink :: RawFilePath -> Key -> CommandPerform
|
|||
makeHardLink file key = do
|
||||
replaceWorkTreeFile (fromRawFilePath file) $ \tmp -> do
|
||||
mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
|
||||
linkFromAnnex key (toRawFilePath tmp) mode >>= \case
|
||||
linkFromAnnex' key (toRawFilePath tmp) mode >>= \case
|
||||
LinkAnnexFailed -> error "unable to make hard link"
|
||||
_ -> noop
|
||||
next $ return True
|
||||
|
|
|
@ -357,7 +357,7 @@ verifyWorkTree key file = do
|
|||
let tmp' = toRawFilePath tmp
|
||||
mode <- liftIO $ catchMaybeIO $ fileMode <$> R.getFileStatus file
|
||||
ifM (annexThin <$> Annex.getGitConfig)
|
||||
( void $ linkFromAnnex key tmp' mode
|
||||
( void $ linkFromAnnex' key tmp' mode
|
||||
, do
|
||||
obj <- calcRepo (gitAnnexLocation key)
|
||||
void $ checkedCopyFile key obj tmp' mode
|
||||
|
|
|
@ -50,7 +50,7 @@ perform dest key = do
|
|||
replaceWorkTreeFile (fromRawFilePath dest) $ \tmp ->
|
||||
ifM (inAnnex key)
|
||||
( do
|
||||
r <- linkFromAnnex key (toRawFilePath tmp) destmode
|
||||
r <- linkFromAnnex' key (toRawFilePath tmp) destmode
|
||||
case r of
|
||||
LinkAnnexOk -> return ()
|
||||
LinkAnnexNoop -> return ()
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue