[tahoe-dev] [tahoe-lafs] #708: graceful handling of capabilities in a format from the future that you can't understand

tahoe-lafs trac at allmydata.org
Fri Jul 3 16:21:37 UTC 2009


#708: graceful handling of capabilities in a format from the future that you
can't understand
-------------------------------+--------------------------------------------
     Reporter:  zooko          |       Owner:  warner               
         Type:  enhancement    |      Status:  closed               
     Priority:  major          |   Milestone:  1.5.0                
    Component:  code-dirnodes  |     Version:  1.4.1                
   Resolution:  fixed          |    Keywords:  forward-compatibility
Launchpad_bug:                 |  
-------------------------------+--------------------------------------------
Changes (by warner):

  * component:  code-encoding => code-dirnodes


Comment:

 The internal 'move' method does just that, and the JSON representation of
 a directory includes all the information we have about the unknown object
 (i.e. both the writecap and the readcap). What I don't know is how the
 CLI-side "tahoe cp" works, specifically if the put-lots-of-caps-at-once
 dirnode webapi operation will accept the same "unknown cap" structure that
 the JSON representation hands down. Also, I wanted to discourage people
 from adding new unknown caps to a directory (because they might just be
 adding complete junk, or a typo, or a blank string, and it'd be nice to
 detect that early), so the current code is liberal in what it accepts from
 the backend, but strict in what it accepts from the frontend, and this
 might prevent the frontend-based tools from doing this sort of copy.

 So yes, I think that approach would be safe, and it might already work.
 (of course we have no way to tell if the unknown-cap is a file or a
 directory, or something even more exotic, so we might be creating a
 hardlink to a mutable directoryish-thing when the rest of the copy
 operation was trying to make a deepcopy of individual files).

 The test would need to go in test_cli.py where it tests the "tahoe cp"
 operation. grep around the test suite for !UnknownNode, you have to be a
 bit sneaky to get the cap-from-the-future into a directory to start with.

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


More information about the tahoe-dev mailing list