Messages in this thread | | | Date | Fri, 2 Jul 1999 15:58:05 +0200 | From | Jamie Lokier <> | Subject | Re: I think I was badly misunderstood, it's all optional |
| |
Richard Gooch wrote: > I'm assuming the new semantics are that read(2)ing a directory yields > the "default" data fork (is this assumption correct?).
That's one possibility yes. lseek(2) must work on the data too.
> If you could clarify: suppose I had an albod (written by KWord or > whatever). Will I still be able to use my existing tools such that the > directory appears as a directory (i.e. for stat() and open() > purposes)?
It's not clear to me if it should appear as a directory or a file. Do we want `find' to enter this thing or not? `rm -rf'? `cp'? `tar'? What if the current on-disk representation is a file because you just wrote it as a flat file? Is it unpacked when it's written or on demand when it's read as a directory?
For consistency with the d_type field from readdir(), which isn't currently returned but should be IMO, it should be a directory. Either that or albods have a new on-disk represenation. Looking for the default file to decide if it's an albod at readdir() time would introduce excessive directory-reading overhead.
It's not even clear that opening with O_DIRECTORY always shows the directory. Care is needed: this is as efficient way to _test_ for a directory, which an optimised `find' would use. (<plug> See my treescan prog </plug>). It may mean implementing d_type from readdir() at last.
> Another question, since it hasn't been made clear to me: which > problem(s) are you trying to solve by adding new semantics for > directories?
Assuming an efficient small-object filesystem (reiserfs or reiserfs on ext2)), I can only think of one: the ability to send them around as files using traditional tools. Thereby implementing the illusion of "documents" which happen to be implemented as directories of their contents.
-- Jamie
ps. To keep things exciting, what about CVS? Should that operate within the albod thereby introducing `CVS' subdirectories into the albod? Or should it operate on the whole albod as a file, thereby being ridiculously coarse-grained and inefficient? (Think EDA "documents" containing hundreds of components).
Perhaps albod-aware tools should generally work with directories, and these kernel-hacks used simply to hint to directory-aware programs whether to enter the directory or not. In which case hybrid directory-files should always look like files.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |