On 7/26/10 12:32 PM, Zooko O'Whielacronx wrote: > Anyway, <so> was wrong that repair works on immutable files and > directories given a verify cap to the thing—instead you require a > read-cap to the thing. Repair also works on mutable files and > directories given a write-cap to the thing (which means you can't let > someone repair a mutable thing while withholding from them the ability > to read it and even to change it).
An update on this: in v1.7.1: mutable files require a writecap to repair immutable files require a readcap to repair in the upcoming v1.8.0: mutable files will still require a writecap to repair immutable files will require a verifycap to repair The problem with mutable files is the shared "write-enabler" secret. If you were to repair a mutable file using only a readcap or verifycap, you wouldn't be able to tell new servers what write-enabler they ought to accept for future updates. So you could improve the health of the current version of the file, but the real writecap holder would not be able to replace those new shares with later versions, meaning the file would slowly become sort of read-only. We will need to move to DSA keypairs (instead of shared secrets) to fix this. The issue with immutable files in 1.7.1 is more of a missing API than a fundamental protocol limitation. When Zooko wrote the immutable repairer (about two years ago), he wisely based it on using a verifycap instead of a readcap, so most of the support is in place already. My upcoming #798 new-downloader code (getting ready to land soon) adds support for downloading ciphertext from a verifycap, and I'm hopeful that we can add the remaining pieces (webapi code to expose the new VerifyNode instances and their .read()/.repair() methods) by the time we release 1.8.0. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
