[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3793: allocate_buckets() should always list all shares in its response

[Tahoe-LAFS]

#3793: allocate_buckets() should always list all shares in its response
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  itamarst
         Type:  defect    |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------

Comment (by itamarst):

 So there's the case where someone else might write different data;
 basically a security attack by predicting keys somehow based on knowing
 person A will upload file F. I'm going to assume that's out of scope and
 either is not possible or will get fixed some other way

 There's also the case where a person starts uploading file A, that fails
 half-way, and they decide to upload file B instead. As far as I can tell
 this ... won't happen due to the way storage indexes are generated.

 So that just leaves the case of uploading file A, and then later trying
 again with file A. Given uploading the same file, with no changes,
 idempotent operations seem just fine, ideal in fact.

 And HTTP needs to support multiple `immutable.ShareFile` instances in
 parallel, otherwise you can't do parallel uploads.

 I therefore propose:

 1. Allow parallel uploads by multiple clients or connections.
 2. Implement write-last semantics.
 3. Half-finished uploads get expired by a timeout, e.g. 48 hours (should
 be long enough that a prospective client has long since given up).

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3793#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage