fix export overwrite on FAT

Don't accept the cid of the temp file that the content has just been
written to as something we will accept if another file has that same
content. There's no reason to, and on FAT, due to mtime resolution,
the test suite hit just such a case.

This fixes a reversion from 73df633a62
which removed inode from the ContentIdentifier.
This commit is contained in:
Joey Hess 2021-01-25 13:31:17 -04:00
parent 9e1a797fb7
commit b63e3118d7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 33 additions and 1 deletions

View file

@ -471,7 +471,7 @@ storeExportWithContentIdentifierM dir src _k loc overwritablecids p = do
Nothing -> giveup "unable to generate content identifier"
Just newcid -> do
checkExportContent dir loc
(newcid:overwritablecids)
overwritablecids
(giveup "unsafe to overwrite file")
(const $ liftIO $ rename tmpf dest)
return newcid

View file

@ -26,3 +26,5 @@ on 8.20201129+git169-gaa07e68ed-1~ndall+1 (presumably... identified 3 regression
[[!meta author=yoh]]
[[!tag projects/datalad]]
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2021-01-25T16:54:58Z"
content="""
Oh this is interesting:
unexport foo import
unsafe to remove modified file
failed
export foo import ok
So despite seeing the file is modified when it is asked to remove it, it
somehow does not notice that when writing to it, so overwrites it
with the content anyway. That's how it ends up with
unexpected content, despite the overall `git-annex export`
failing as expected.
And the root cause is, the test suite writes to the file on the remote,
and then Remote.Directory writes to a temp file, and then gets its content
identifier (mtime), and for some reason accepts that content identifier as
one it can overwrite. Due to the timestamp resolution, that's the same
content identifier as the newly written file on the remote. So it
overwrites it.
I can't find any good reason for it to accept the temp file's content
identifier as a known content identifier, which it's always done. Other remotes
don't do that. So I think this is a real bug in Remote.Directory and will
fix it there.
"""]]