fix to use 1 chunk for empty file

Fix retrival of an empty file that is stored in a special remote with
chunking enabled.

The speculative chunk stuff caused a reversion by adding an empty list for
the empty file. Which is just wrong; the empty file is still stored on the
remote, and should be retrieved like any other file. It uses 1 chunk, so
`max 1` is the simple fix.

Sponsored-by: Noam Kremen on Patreon
This commit is contained in:
Joey Hess 2022-06-09 14:24:56 -04:00
parent f30532614f
commit 13fc6a9b6a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 23 additions and 1 deletions

View file

@ -6,6 +6,9 @@ git-annex (10.20220526) UNRELEASED; urgency=medium
The location value no longer needs to match the url of an existing The location value no longer needs to match the url of an existing
git remote, and locations not using ssh:// will work now, including git remote, and locations not using ssh:// will work now, including
both paths and host:/path both paths and host:/path
* Fix retrival of an empty file that is stored in a special remote with
chunking enabled.
(Fixes a reversion in 8.20201103)
-- Joey Hess <id@joeyh.name> Wed, 01 Jun 2022 13:23:05 -0400 -- Joey Hess <id@joeyh.name> Wed, 01 Jun 2022 13:23:05 -0400

View file

@ -554,7 +554,7 @@ chunkKeys' onlychunks u chunkconfig k = do
Nothing -> l Nothing -> l
Just keysz -> Just keysz ->
let (d, m) = keysz `divMod` fromIntegral chunksz let (d, m) = keysz `divMod` fromIntegral chunksz
chunkcount = d + if m == 0 then 0 else 1 chunkcount = max 1 (d + if m == 0 then 0 else 1)
v = (FixedSizeChunks chunksz, chunkcount) v = (FixedSizeChunks chunksz, chunkcount)
in if v `elem` recorded in if v `elem` recorded
then l then l

View file

@ -86,3 +86,5 @@ so I do not think it is an issue of the remote (which might also have some size
tried both 8.20211123 and 10.20220504 from debian tried both 8.20211123 and 10.20220504 from debian
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2022-06-09T18:05:15Z"
content="""
This was broken by [[!commit dad4be97c2057db1ef3a13bb983d1701a90c9069]].
For a key of size zero, `addspeculative` adds on a `[]` to the list of chunk
key. But that causes retrieveChunks to think that it's already retrieved
all the chunks, so it avoids doing any retrieval, so the file is not
written. It needs to retrieve the empty key even though it's empty,
so it can decrypt it when it's encrypted; git-annex does not special case
empty file retrieval.
Odd that testremote did not detect this. It does test with empty keys, and
with chunking.
"""]]