[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
Thu Jul 2 21:26:03 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-encoding | Version: 1.4.1
Resolution: fixed | Keywords: forward-compatibility
Launchpad_bug: |
-------------------------------+--------------------------------------------
Changes (by zooko):
* status: new => closed
* resolution: => fixed
Comment:
Over on [comment:5:ticket:683 ticket #683, comment 5], Brian wrote:
> [3960] changes the way dirnodes are processed to tolerate unrecognized
URIs. This should make tahoe-1.5 able to survive new formats that come
from the future (i.e. if a 1.5 client tries to read or modify a directory
which has new-format entries which were placed there by some 1.6-or-beyond
version). It's at least a start.
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.
Brian: would there be any danger in that approach?
I don't know how important it would be for clients from the past to be
able to copy your new-style caps.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/708#comment:6>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list