Re: silent semantic changes with reiser4

[Nicholas Miell <nmiell@gmail.com>]

On Wed, 2004-08-25 at 21:44, Matt Mackall wrote:
> On Wed, Aug 25, 2004 at 05:42:21PM -0700, Nicholas Miell wrote:
> > On Wed, 2004-08-25 at 16:46, Wichert Akkerman wrote:
> > > Previously Jeremy Allison wrote:
> > > > Multiple-data-stream files are something we should offer, definately (IMHO).
> > > > I don't care how we do it, but I know it's something we need as application
> > > > developers.
> > > 
> > > Aside from samba, is there any other application that has a use for
> > > them? 
> > > 
> > 
> > Anything that currently stores a file's metadata in another file really
> > wants this right now. Things like image thumbnails, document summaries,
> > digital signatures, etc.
> 
> That is _highly_ debatable. I would much rather have my cp and grep
> and cat and tar and such continue to work than have to rewrite every
> tool because we've thrown the file-is-a-stream-of-bytes concept out
> the window. Never mind that I've got thumbnails, document summaries,
> and digital signatures already.
> 
> While the number of annoying properties of files with forks is
> practically endless, the biggest has got to be utter lack of
> portability. How do you stick the thing in an attachment or on an ftp
> site? Well you can't because it's NOT A FILE. 
> 
> A file is a stream of bytes.

"OMG! It breaks tar and email!!!" argument doesn't fly. Things break all
the time and are fixed. It's called progress.

cp, grep, cat, and tar will continue to work just fine on files with
multiple streams.

tar and cp will lose the extra streams until somebody fixes them, but
they lose ACLs and xattrs right now, and I don't hear anybody suggesting
that ACLs and xattrs be removed from the kernel because of this.

Fixing programs that do recursive filesystem traversals is a matter of a
glibc patch to nftw(3) and a modification to their option processing.

Holding back a useful feature because you don't want to upgrade
coreutils is just plain dumb.

(BTW, for email, multipart/parallel is a start, but a specific multipart
content type for multi-stream file attachments would probably be more
appropriate.)