Re: The argument for fs assistance in handling archives

Helge Hafting
2004-09-09T11:18:33Z

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