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

[tahoe-lafs]

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

Comment (by davidsarah):

 In webapi.rst, 'webapi' -> 'web-API'.

 The time to do an {{{os.stat}}} on a file that does not exist and catch
 the resulting {{{OSError}}}, seems to be around 0.005 ms on my machine.
 Are we sure that it isn't premature optimization to avoid this check on
 each web-API request if it didn't exist at start-up?

 (For some reason it is faster to catch the exception from {{{os.stat}}}
 than to use {{{os.path.exists}}}. A significant part of the difference is
 just the time to do the {{{.path}}} and {{{.exists}}} accesses, which
 shows a) how unoptimized CPython is, and b) that we shouldn't worry too
 much about OS calls being expensive relative to Python code.)

 If the {{{access.blacklist}}} file is deleted while a node is running,
 subsequent requests will fail.

 It seems more usable to allow the reason to contain spaces. I know this
 complicates extending the format to have additional fields, but we
 probably won't need that, and if we did then we could use something like
 {{{
 storage_index;new_field The men in black came round to my house.
 }}}

 The line wrapping changes to {{{create_node_from_uri}}} are not necessary;
 I don't object to them but they probably shouldn't be in this patch.

 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.)

 When an access is blocked, the SI of the file should probably be logged.
 (I think the failed request will already be logged, but the exception only
 gives the reason string, which isn't necessarily unique to a file.)

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