turns out this was fixed in 2014
This commit is contained in:
parent
2f96e15eda
commit
4d063f12c6
2 changed files with 11 additions and 0 deletions
|
@ -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
|
||||
|
|
|
@ -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]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue