Re: The argument for fs assistance in handling archives

[Spam]

> 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.

  Are you afraid to learn something new? ;) Just joking. But really,
  it doesn't have to be very difficult. The extra streams etc would
  just be saved as files. If tar is patched then it would be no
  problem and no extra stuff but perhaps a switch --save-metas.

> 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.

  Actually MacOS and Windows support multiple streams, only Linux
  doesn't. But of course there are BSD's etc too. I'd say to leave
  them behind.

  The file streams would make my day a lot easier. The idea to
  split up contents of OO.org files into streams is bad. But that
  doesn't make the file streams bad. I see many uses that would make
  my every day life easier.

  It isn't about cross plat form compatibility, but to add features
  that are useful and meta-data and file streams are.

  Also. No one forces you to use either meta-data or streams, just as
  no one forces you to use ACLs or other things.

> 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.)

  I do not think the Samba would really require the streams support
  but it would certainly make life easier for Samba. Not to mention
  that these files would also be natively viewed on the Linux host.

> 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... 

  I would agree with tunnel vision. The kernel should provide the
  tools and options. Users and developers can then invent new things
  to use them. :)

  ~S

> -Steve Bergman

-
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/