[tahoe-lafs-trac-stream] [tahoe-lafs] #2110: uploader confuses self-write-dedup with "server is full"

[tahoe-lafs]

#2110: uploader confuses self-write-dedup with "server is full"
--------------------------+----------------------------
 Reporter:  zooko         |          Owner:  markberger
     Type:  defect        |         Status:  new
 Priority:  normal        |      Milestone:  undecided
Component:  unknown       |        Version:  1.10.0
 Keywords:  upload error  |  Launchpad Bug:
--------------------------+----------------------------
 I just got this on my !LeastAuthority.com S4 server, and then I verified
 by code inspection that it is also present in trunk. I haven't yet
 verified if it is also present in 1382-rewrite-2. If you write to a server
 and ask to allocate a bucket, and it writes back saying that it won't
 allocate that bucket for you, and by the way that it doesn't already have
 that bucket available to you, the client reasonably-enough concludes that
 the server is full. It reports that server as having been full if the
 upload fails. This gave me a bit of a start, since I couldn't figure out
 how Amazon S3 could be "full" so I thought there was a bug in my S4
 service. ☺ But the truth appears to be that I was already uploading the
 same (immutable) file and the upload was in-progress, so the server was
 unwilling to start a new upload and also unwilling/unable to let me do a
 download.

 I suspect the only real solution to this is going to be to extend the
 "get_bucket"/"allocate_buckets" protocol for immutable files so the server
 can mention to the client "... and by the way the reason that I won't take
 it and also won't give it to you is that there is a *partial* upload of
 that same file sitting here. So you might want to report to your human
 that they could try again in a few minutes and see if that one has
 finished".

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