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.
next prev parent 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]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).