Re: The argument for fs assistance in handling archives
From: Helge Hafting
Date: Thu Sep 09 2004 - 06:20:10 EST
Tonnerre wrote:
Salut,
On Wed, Sep 08, 2004 at 11:24:40AM +0200, Helge Hafting wrote:
If you can open a fork/substream/whatever by issuing
open("filename/forkname", ...
then the old-fashioned open() works with multi-fork files too.
An tools based on "open() something, then work with
the resulting file descriptor" will work _unchanged_
with such a multi-fork fs.
In my version they'd run unchanged as well.
And BTW, I wasn't talking about introducing a new open at libc
level. I was talking about modifying the open system call in the
kernel and having libc provide compatibility for the old call.
Since I'm not sure how much breakage it takes to make a file a
directory.
I believe most of the changes necessary for supporting file-as-dir
will be in the internal workings of filesystems, not so much in
the interfaces. I don't think it is necessary to change the
open system call, because opening a file in a subdirectory
or a named substream is the same thing.
The _uses_ people have suggested for file-as-dir (complex file attributes
and different views of the data) tends to be different from what
a directory usually does, but the implementation doesn't have to be.
There's no need to add extra interfaces or restrictions. File-as-dir that
really is a directory, so that it may contain a whole tree is more flexible.
And the underlying fs can use existing directory code instead of
something extra.
So the only change needed for the open system call is that it will
suddenly succeed in the open("filename/forkname") case that
used to complain about an invalid path because "filename" isn't a
directory.
"stat" may have to change though, so it can identify a file-as-dir.
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/