On 6/3/11 11:45 AM, Zooko O'Whielacronx wrote: > On Fri, Jun 3, 2011 at 4:28 AM, Greg Troxel <[email protected]> wrote: >> >> But, in wiki:Capabilities, it says that a directory is just a mutable >> file with special interpretation. > > This is perhaps a misleading statement. The "special interpretation" > includes an added layer of decryption. Probably that statement should > just be struck from wiki:Capabilities.
Hm, I kinda disagree. The "special interpretation" means parsing the file's contents to build a mapping from child names to child caps, then providing a different set of methods (dirnodes have list/get/add/replace/remove, files have read/write). (ok, plus the extra decryption, but that's less significant than the table-parsing). Maybe we should clarify it to explain that directories are *backed* by files. I remember using that "just a mutable file" phrase to teach the reader that they didn't need to be afraid of dirnodes; that they were re-using existing technology (which the reader would already understand, having read about mutable files in the previous chapters), and only emphasizing the new parts (the layer of interpretation that makes dirnodes special). >> but I expected to get the directory contents. > > Change the URI from URI:DIR2etc. to URI:SSKetc. Oh, I just thought of a precedent for this *not* working as you expected. Once upon a time in the UNIX world, when directories were fairly new, you could 'cat' or 'vi' a directory, and you'd get a weird-looking file with some filenames and some other binary gunk. In theory you could probably edit that "file" to modify the directory, but nobody sane would do that directly. Only tools like "mv" did stuff like that, and eventually that functionality was moved down into the kernel and the filesystem code. Later, when the authors wised up and realized that allowing this sort of pseudo-casting wasn't helping anyone but filesystem hackers, they made it an error to use open() on a directory. Tahoe's webapi behaves like the latter/wiser UNIX interface. cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
