lkml.org 
[lkml]   [1999]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.018 / U:23.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site