[tahoe-lafs-trac-stream] [tahoe-lafs] #666: Accounting: limit storage space used by different parties

[tahoe-lafs]

#666: Accounting: limit storage space used by different parties
------------------------------+------------------------
     Reporter:  warner        |      Owner:
         Type:  task          |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.3.0
   Resolution:                |   Keywords:  accounting
Launchpad Bug:                |
------------------------------+------------------------

Comment (by zooko):

 https://github.com/davidsarah/tahoe-
 lafs/blob/666-accounting/src/allmydata/storage/leasedb.py#L171

 I don't understand the comment about a share having been deleted from on-
 disk. So the case is that the share itself may be gone, but the share
 entry in the leasedb is still in place, and then someone calls
 {{{add_new_share}}} on it? And this triggers a
 {{{dbutil.IntegrityError}}}, but we want to resolve it as a success? The
 {{{FIXME}}} sounds a little scary. I guess the fix would be to see whether
 this particular {{{dbutil.IntegrityError}}} instance is being raised
 because the row (or at least the primary key) already exists in the table
 vs. some other integrity error.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/666#comment:6>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage