turns out this was fixed in 2014

diff --git a/Remote/Helper/Chunked.hs b/Remote/Helper/Chunked.hs
index 2ef8360181a18fe331590c2978b04b1eda1ae793..0cd316a4ba92ddab41982c8fd1682db336afc8ff 100644 (file)
--- a/Remote/Helper/Chunked.hs
+++ b/Remote/Helper/Chunked.hs
@@ -120,6 +120,10 @@ storeChunks
        -> Annex ()
 storeChunks u chunkconfig encryptor k f p storer checker = 
        case chunkconfig of
+               -- Only stable keys are safe to store chunked,
+               -- because an unstable key can have multiple different
+               -- objects, and mixing up chunks from them would be
+               -- possible without this check.
                (UnpaddedChunks chunksize) -> ifM (isStableKey k)
                        ( do
                                h <- liftIO $ openBinaryFile f ReadMode

diff --git a/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn b/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
index 1183398175767f832305600bc581dce81c1988f2..677dd49043eeb59e52aa5f9b5dcd2918790f3ba2 100644 (file)
--- a/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
+++ b/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
@@ -39,3 +39,10 @@ since it can fail so badly with them, and they're kind of a side thing?
 (Could continue retrieving, for whatever is stored hopefully w/o being
 corrupted already.)
 --[[Joey]]
+
+> This would also affect any key that is not stable.
+> And oh, it stopped using chunks to store non-stable keys in 2014.
+> 
+> So, this can't really happen with url keys, because they're not stable.
+> Ok, not a bug then, because if the key is stable, there can only be one
+> object for it, by definition. Whew! [[done]] --[[Joey]]