From 4d063f12c687b109e05aaea028f88598ef49971b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 22 Oct 2020 19:54:26 -0400 Subject: [PATCH] turns out this was fixed in 2014 --- Remote/Helper/Chunked.hs | 4 ++++ ...possible_data_loss_when_unsized_key_stored_chunked.mdwn | 7 +++++++ 2 files changed, 11 insertions(+) diff --git a/Remote/Helper/Chunked.hs b/Remote/Helper/Chunked.hs index 2ef8360181..0cd316a4ba 100644 --- 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 1183398175..677dd49043 100644 --- 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]]