[tahoe-dev] [tahoe-lafs] #839: Copying directories containing caps from the future

[tahoe-lafs]

#839: Copying directories containing caps from the future
-----------------------------------+----------------------------------------
 Reporter:  davidsarah             |           Owner:           
     Type:  defect                 |          Status:  new      
 Priority:  major                  |       Milestone:  undecided
Component:  code-frontend-cli      |         Version:  1.5.0    
 Keywords:  forward-compatibility  |   Launchpad_bug:           
-----------------------------------+----------------------------------------
 #708 left the following forward-compatibility issue unresolved:

 >As I understand it, the fact that we can't add unknown caps into a
 directory means that we can't copy directories which contain caps from the
 future. (If we do copy such a directory then the entries in it which had
 new-style caps will be omitted from the newly created copy of the
 directory). In theory it should be possible to do that safely just by
 copying the write-cap field from the entry in the source dir into the
 write-cap field of the newly created entry in the target dir, and likewise
 copying the read-cap.
 [...]
 >I don't know how important it would be for clients from the past to be
 able to copy your new-style caps.

 I think it's important. If we add a completely new cap format, then will
 be quite possible to end up with a mixture of new and old caps in a
 directory, especially if multiple people are using it. It would be nice
 for old clients to be able to copy such a directory, at least for
 immutable files (where copying is equivalent to referencing). Where a new
 cap references a mutable file, it's less clear what to do.

 Continuing the discussion from #708:
 >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.

 To close this issue:
  * find out whether copying caps-from-the-future already works from the
 CLI
  * decide whether it should work
  * if it should work and doesn't, then make it work
  * add tests.

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