Re: The argument for fs assistance in handling archives

Helge Hafting
2004-09-08T09:21:23Z

Tonnerre wrote:

>Salut,
>
>On Fri, Sep 03, 2004 at 10:22:55AM +0200, Helge Hafting wrote:
>
>
>>Requiring another syscall to open forks other than the primary
>>breaks _all_ existing software because it obviously don't use that
>>syscall yet. And then it doesn't provide any advantages over the
>>file-as-plain-directory way. . .
>>
>>
>
>Actually...
>
>We might tune the sys_open() call to take an additional argument (the
>stream ID), and introduce a compatibility interface into *libc which
>chooses strid=0 by default if the plain old open call is being used.
>
>
But this isn't necessary, as I pointed out above.
There is no _need_ for a new kind of open(), so
why make one in libc?

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.

Tools that rely on "stat" or directory traversals might need
some updating to work perfectly with such a fs, but not something
that just opens by name.

Helge Hafting