Re: The argument for fs assistance in handling archives

Helge Hafting
2004-09-06T13:21:40Z

Horst von Brand wrote:

>Helge Hafting <helge.hafting@hist.no> said:
>
>[...]
>
>
>
>>The only new thing needed is the ability for something to be both
>>file and directory at the same time.
>>
>>
>
>Then why have files and directories in the first place?
>
>
>
>> Some tools will need
>>a update - usually only because they blindly assume that a directory
>>isn't a file too, or that a file can't be a directory too. Remove the
>>mistaken assumption and things will work because the underlying system
>>calls (chdir or open) _will_ work.
>>
>>
>
>But with some weird restrictions: No moving stuff around between files, no
>
>
I see no need for such a weird restriction. If it is "weird", why have it?
If someone want to move stuff from one subdirectory to another, let them.
I see no need to stop that just because a file-as-directory was involved.

>linking, some "files" can't be deleted (how would you handle removing the
>
>
linking is a problem of course. We can't have hardlinks to directories,
so no hardlinks to file-as-dir either unless the general problems with
directory links are solved.

>principal stream of a file?).
>
A design decision. Removing the principal stream may delete
the entire tree. Or it may delete the principal stream only,
turning that file-as-dir back into a plain directory.

>Some stuff you'd love to do (is, in fact, the
>reason for this all) just can't be allowed (i.e., J. Random Luser setting
>his own icon for system-wide emacs). So the tools/scripts/users/sysadmins
>will have to be painfully aware that some of the files aren't, and some of
>the directories aren't either. Major pain in the neck to use, if you look
>closer. Add extra kernel complexity. For little (if any) gain.
>
>
The gain is indeed the interesting question here. It isn't something
I desperately need. But if file-as-directory _happens_, then I hope
it'll happen in a good way. No unnecessary complications or restrictions,
and allowing existing stuff to work as well as possible. There will
surely be some
tool problems - but we certainly don't need to break every existing
tool the way a new form of "open" will. . .

Helge Hafting