Re: The argument for fs assistance in handling archives

Steve Bergman
2004-09-02T19:52:24Z

On Thu, 2004-09-02 at 11:22 -0700, Martin J. Bligh wrote:
> > For 30 years nothing much has happened in Unix filesystem semantics
> > because of sheer cowardice
>
> Or because it works fine, and isn't broken.

OK. I'm not a kernel hacker. I'm not a crack C programmer. Nor am I a
designer of filesystems. I'm just a guy that puts together and supports
Linux systems for my customers.

In following this thread, I may be missing huge chunks of concept.

However, a few things are becoming clear to me:

1. The file as directory thing adds complexity that the administrator
has to deal with. Symlinks are useful, but it's still aggravating to
tar off a directory structure, take it somewhere, and then realize that
all you have is links to something not in the archive because you didn't
get your tar switches just right. Now we're talking about adding
another set of "files which are not really files" to the semantics.
More complexity. I'll take simplicity over some ivory tower ideal of
"unified name space" any day.

2. The use of multiple streams within files by Linux apps would make
Linux as cross-platform unfriendly as MS is trying to be. Say these
features start getting used and you copy an OO.org document from a Linux
box to a BSD box. It's broken. Of course, OO.org wouldn't use the
streams in the first place because it would destroy their cross platform
portability. So what's the point? No one who cares about cross
platform portability can use it. Everyone who doesn't care about cross
platform portability please raise your hand.

3. MS does require attributes and multiple streams, which makes these
features important (even essential) to Samba, and Samba alone. Samba is
important to Linux, so this can't be ignored. (Here I am implicitly
assuming that Samba will need kernel support for this to do it right.)

So it seems to me that the only real consideration is giving Samba what
it needs without making the semantics one bit more complex than
absolutely necessary. It might even be wise to discourage use of these
ambiguous new objects by the casual application programmer.

Then again, maybe I just have tunnel vision...

-Steve Bergman