[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3801: Clarify behavior of overwriting in immutable uploads

[Tahoe-LAFS]

#3801: Clarify behavior of overwriting in immutable uploads
----------------------+---------------------------------------
 Reporter:  itamarst  |          Owner:  itamarst
     Type:  task      |         Status:  new
 Priority:  normal    |      Milestone:  HTTP Storage Protocol
Component:  unknown   |        Version:  n/a
 Keywords:            |  Launchpad Bug:
----------------------+---------------------------------------
 This is related but not quite the same as #3793.

 1. Current interactions from Fooslcap when uploading an immutable
 basically upload in order. With HTTP, uploads can happen out of order. How
 to handle holes?
 2. Immutables are supposed to be immutable. As such, the data changing
 between different write attempts to the same in-progress immutable
 suggests something went very wrong.
 3. Current behavior is "last write wins". This could potentially lead to
 unexpected outcomes if there are bugs.

 Alternative behaviors to current behavior include:

 1. Disallow overlapping writes.
 2. Allow overlapping writes so long as data is unchanged.

 In either case the need to deal with out-of-order writes remains due to
 HTTP. Current code might work, but would result in holes that then get
 overwritten. Policies that explicitly forbid/validate overlapping writes
 would need to deal with holes.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3801>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage