fix to use 1 chunk for empty file
authorJoey Hess <joeyh@joeyh.name>
Thu, 9 Jun 2022 18:24:56 +0000 (14:24 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 9 Jun 2022 18:24:56 +0000 (14:24 -0400)
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
CHANGELOG
Remote/Helper/Chunked.hs
doc/bugs/error_out_on_file_size_0_from_external_spec_remote.mdwn
doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment [new file with mode: 0644]

index ae14d55acd31b70bad667d72e99fe2ab9ed4eca5..24b3c6cb5bb60362d13b170dd2963a33af92ce6c 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,6 +6,9 @@ git-annex (10.20220526) UNRELEASED; urgency=medium
     The location value no longer needs to match the url of an existing
     git remote, and locations not using ssh:// will work now, including
     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
 
index a8d928c597f64ad4151b0ad7e2345e43c722c51f..72e33fe77e87ca4671a0a4ecd79e1cd70ef03b4e 100644 (file)
@@ -554,7 +554,7 @@ chunkKeys' onlychunks u chunkconfig k = do
                        Nothing -> l
                        Just keysz -> 
                                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)
                                in if v `elem` recorded
                                        then l
index b2358f32a3e0599d4e35fa79481bffa64c9e131e..a2ad89262879affeba0cbd6ae64e4c28ab4dacf2 100644 (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 
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment b/doc/bugs/error_out_on_file_size_0_from_external_spec_remote/comment_2_1d78459554bc12d0423a317bd9f466d1._comment
new file mode 100644 (file)
index 0000000..a37c6f1
--- /dev/null
@@ -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.
+"""]]