[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 09:21:37 PDT 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