[tahoe-lafs-trac-stream] [tahoe-lafs] #1425: blacklist support

[tahoe-lafs]

#1425: blacklist support
-----------------------------------+--------------------
     Reporter:  warner             |      Owner:  warner
         Type:  enhancement        |     Status:  new
     Priority:  major              |  Milestone:  1.9.0
    Component:  code-frontend-web  |    Version:  1.8.2
   Resolution:                     |   Keywords:
Launchpad Bug:                     |
-----------------------------------+--------------------

Comment (by davidsarah):

 Replying to [comment:6 zooko]:
 >  If a request happens at the same time as the access.blacklist file is
 being rewritten, the request may reread an incomplete copy of the file.
 (The process that rewrites access.blacklist could avoid this by writing
 the new file and then moving it into place, but the patch doesn't document
 that this is necessary, and also it won't work on Windows.)
 >
 > If you use
 [http://twistedmatrix.com/documents/current/api/twisted.python.filepath.FilePath.html#setContent
 FilePath.setContent] then your code can be simple while having this
 behavior. In addition, on Windows it will write to a new file, delete the
 old file, move the new file into place. That should, if I understand
 correctly, guarantee that an uncoordinated reader will see one of (old
 file, new file, no file).

 Currently if the node sees no file, the blacklist code will raise an
 exception (I think this will just fail the request rather than crashing
 the node). I suppose that fails safe, but it's still undesirable.

 In any case, someone editing the file probably won't be using !FilePath.
 They might use an editor that does the atomic rename-into-place; it's not
 uncommon for editors to do that on Unix, but it's not good for usability
 to expect users to know whether their editor does that.

 If we had a {{{tahoe}}} command to add and remove entries from the
 blacklist, that command could tell the node when to reread it, maybe (or
 the add/remove operations could be web-API requests, but that would be
 more complicated).

 Alternatively, we could just document that the node always needs to be
 restarted after editing the blacklist.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1425#comment:7>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage