From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hr2.samba.org ([144.76.82.148]:40968 "EHLO hr2.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726955AbeH0UUj (ORCPT ); Mon, 27 Aug 2018 16:20:39 -0400 Date: Mon, 27 Aug 2018 09:33:10 -0700 From: Jeremy Allison To: "Theodore Y. Ts'o" Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, Eric Biggers , samba-technical@lists.samba.org, jra@samba.org Subject: Re: Streams support in Linux Message-ID: <20180827163310.GA217636@jra3> Reply-To: Jeremy Allison References: <20180825135107.GA12251@bombadil.infradead.org> <20180825162547.GA10619@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180825162547.GA10619@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.