Brian Warner <[email protected]> writes: > 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).
As someone trying to understand, without reading the code, something like: A directory is stored as a mutable file. It contains a mapping from names to three items: a read-only capability to the item, a read-write capability to the item (optional), and attributes such as modification times. The read-write version of the capability is further encrypted in a key that is contained in directory writecaps but missing from the corresponding readcap. would be sufficient (from using SSK instead of DIR2 and reading the output with emacs). I see your point about making a directory an abstract object that is implemented by mutable file storage, but I think that deviates from unix filesystem nomenclature enough not to be helpful. The above sort of says "instead of an inode, we use caps, and we add metadata about the time the object was added to the directory". >>> 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. I can do "cat ." on NetBSD 5.1 and pipe it to od and get inode numbers out (with effort, and header files). As far as I know that's always worked, but I haven't tried on Linux. (Amusingly ls calls getdents() which returns things that look like UFS inodes for any filesystem.) (I of course agree that writing to directories is banned, for good reason.) It also seems like when I use a writecap to fetch a directory that the contents should have the embedded writecaps decrypted for me. So I think the right bug is not that 302 is a wierd error message, but that the contents aren't a) returned and b) have writecaps decrypted with writecaps.
pgpyvWBJaSVlI.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
