Curtis Anderson wrote:
[...]
> I could copy all of the kernel code and machinery that supports directories
> into my attribute support code files, or I could go the other direction.
> Since duplicate code is generally a bad idea, starting with directories is
> better. What I now need is a flag in a regular old directory that says that
> this is not really a directory, it is a "compound file". Once I've decided
> to start from directories, I can simplify things by using the regular old
> directories the kernel code provides and implement my "compound files" in
> libc by simple pathname manipulation. I could even slime by a bit and put
> the flag saying this is a "compound file" into the file/directory name,
> something like "foo.d" instead of simply "foo".
>
> So, I can implement stream-style "extended attributes" using code in libc
> and a few conventions. I could even simply document the technique and leave
> it up to the application developers who want EA's to put the required code
> directly into their application. Wow, I've just implemented stream-style
> extended attributes without actually writing any code at all!
This is where your lucid exposition gets murky. It's not enough to
simply document it, you actually have to make the changes in libc, or
wherever you plan to make them. Documentation isn't enough.
> In sum, "stream style extended attributes" is an oxymoron, they are neither
> "extended" nor "attributes". Streams are what we have now in regular files,
> and directories are perfectly suited to storing the "attributes" of that
> directory, er, I should have said "file".
So it's not clear how you reached to the conclusion that directories
shouldn't be pressed into service as compound files. I'm sure you have
a reason, but it wasn't revealed here!
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
