Re: Streams support in Linux

[Steve French <smfrench@gmail.com>]

On Sat, Aug 25, 2018 at 5:37 PM Al Viro via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> On Sat, Aug 25, 2018 at 01:57:16PM -0700, Matthew Wilcox wrote:
>
> > > > Right, but that code also assumes it's dealing with files.
> > >
> > > I'm looking forward to your analysis of all code related to dentry tree,
> > > with an eye towards the places where such asserts are quietly made...
> >
> > I really was hoping not to change the dentry tree at all.
>
> Umhm...  Just what, pray tell, would be used to hold the stream name when
> you are creating/removing/renaming it?  And why are we talking about the
> use of existing syscalls for that thing?  In effect, you are multiplexing
> entirely new syscalls, with different pathname resolution, etc. upon the
> existing ones, using that new AT_... flag to select them.
>
> Better yet, you need some new objects to represent those things, since
> you don't want any informative dentries.  And not fs-private ones, at
> that, since those new syscalls of yours would have to operate on them
> (after all, renaming something opened would probably be expected to
> have the opened descriptor to keep accessing the same object, wouldn't
> it?)

These are interesting questions, and there are cases where streams
have been shown to have value in Windows, and for Apple (in Macs).
Don't know whether the Solaris equivalent was useful - but presumably
was.

Samba has had mixed feelings about streams (see various emails
from JRA e.g.) due to concerns that we don't want to accidentally
create security holes (and some Windows admins don't like streams
because virus checkers have to check them for viruses, not just
the normal file data - $DATA).   Unfortunately, whether Samba,
in a perfect world, would want streams - the "Content Indexing
Service" (and to some extent Internet Explorer) rely on streams
for some useful information (and perhaps to support Mac clients
really well it is even more important).

In the current implementation of cifs.ko we can enumerate
alternate data streams (via an ioctl) - this would be nice to
convert to a standard interface so NTFS and CIFS/SMB3
etc. could use similar tools to list streams.   It is not really
possible to open alternate data streams with cifs.ko if
posix path mapping is enabled (since a ":" in a filename such
as "filename:streamname" would get remapped (to SFM_COLON ie 0xF022
just as Macs do)  as ":" is a reserved character in CIFS/SMB2/SMB3
but not in POSIX.

If there were a way to open streams that would be a help (if
nothing else for backup applications which have to go through hoops
of turning off posix path name mapping in order to get at stream data
today with cifs.ko)

-- 
Thanks,

Steve