All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Allison <jra@samba.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel@vger.kernel.org, Eric Biggers <ebiggers@kernel.org>,
	samba-technical@lists.samba.org, jra@samba.org
Subject: Re: Streams support in Linux
Date: Mon, 27 Aug 2018 09:33:10 -0700	[thread overview]
Message-ID: <20180827163310.GA217636@jra3> (raw)
In-Reply-To: <20180825162547.GA10619@thunk.org>

On Sat, Aug 25, 2018 at 12:25:47PM -0400, Theodore Y. Ts'o via samba-technical wrote:
> On Sat, Aug 25, 2018 at 06:51:07AM -0700, Matthew Wilcox wrote:
> > 
> > Let's go over the properties of a file stream:
> > 
> >  - It has no life independent of the file it's attached to; you can't move
> >    it from one file to another
> >  - If the file is deleted, it is also deleted
> >  - If the file is renamed, it travels with the file
> >  - If the file is copied, the copying program decides whether any named
> >    streams are copied along with it.
> >  - Can be created, deleted.  Can be renamed?
> >  - Openable, seekable, cachable
> >  - Does not have sub-streams of its own
> >  - Directories may also have streams which are distinct from the files
> >    in the directory
> >  - Can pipes / sockets / device nodes / symlinks / ... have streams?  Unclear.
> >    Probably not useful.
> 
> Let's *not* make the mistakes Solaris did, and don't allow an fchdirat()
> into a streams directory.  Let's also not allow executing
> rootkits^H^H^H^H^H^H^H^H binaries as a stream.   :-)

After long and bitter experience with them, I have
come to the conclusion (aided greatly by Ted :-) that
streams are a *FUNDAMENTAL* mistake in filesystem
APIs and we should not have them implemented in
Linux.

I don't write the code, so don't get to chose
of course, but if I had to chose one essential
feature between file streams and RichACLs (which
are already supported for NFSv4) I would chose
RichACLs every time.

For anyone who is claiming that streams are essential
for Windows or Mac application compatibility I'd advise
them to take a look at the initial implementation of
Microsoft ReFS (which didn't support streams, might
do now) and Microsoft Azure SMB file server, which
*still* doesn't support named streams (although I'm
sure they're working on it):

https://docs.microsoft.com/en-us/rest/api/storageservices/features-not-supported-by-the-azure-file-service

Now tell me, if streams are so essential, how are
Microsoft getting *anyone* to migrate to Azure SMB
file service ?

Please let's not make the same mistake Windows NTFS
did here.

Jeremy.

  reply	other threads:[~2018-08-27 20:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-25 13:51 Streams support in Linux Matthew Wilcox
2018-08-25 14:47 ` Al Viro
2018-08-25 15:51   ` Matthew Wilcox
2018-08-25 18:00     ` Al Viro
2018-08-25 20:57       ` Matthew Wilcox
2018-08-25 22:36         ` Al Viro
2018-08-26  1:03           ` Steve French
2018-08-27 17:05             ` Jeremy Allison
2018-08-27 17:41               ` Jeremy Allison
2018-08-27 18:21               ` Matthew Wilcox
2018-08-27 18:45                 ` Al Viro
2018-08-27 19:06                 ` Jeremy Allison
2018-08-28  0:45                 ` Theodore Y. Ts'o
2018-08-28  1:07                   ` Steve French
2018-08-28 18:12                     ` Jeremy Allison
2018-08-28 18:32                       ` Steve French
2018-08-28 18:40                         ` Jeremy Allison
2018-08-28 19:43                           ` Steve French
2018-08-28 19:47                             ` Jeremy Allison
2018-08-28 20:43                               ` Steve French
2018-08-28 20:47                                 ` Jeremy Allison
2018-08-28 20:51                                   ` Steve French
2018-08-28 21:19                                   ` Stefan Metzmacher
2018-08-28 21:22                                     ` Jeremy Allison
2018-08-28 21:23                                     ` Steve French
2018-08-29  5:13                                       ` Ralph Böhme
2018-08-29 13:46                       ` Tom Talpey
2018-08-29 13:54                         ` Aurélien Aptel
2018-08-29 15:02                           ` Tom Talpey
2018-08-29 16:00                             ` Jeremy Allison
2018-08-29 15:59                         ` Jeremy Allison
2018-08-29 18:52                           ` Andreas Dilger
2018-08-26 20:30           ` Matthew Wilcox
2018-08-25 16:25 ` Theodore Y. Ts'o
2018-08-27 16:33   ` Jeremy Allison [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-09-20  2:06 Shahbaz Youssefi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180827163310.GA217636@jra3 \
    --to=jra@samba.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.