Displaying streams as xattrs

[Jeremy Allison]

On Thu, May 25, 2023 at 08:49:47PM +1000, ronnie sahlberg wrote:
>>
>> just took a look at how the ntfs-3g module is handling this. It was an option
>> streams_interface=value, which allows "windows", which means that the
>> alternative data streams are accessable as-is like in Windows, with ":" being
>> the separator. This might be a nice option for cifsfs also. That option would
>> just be usable if no posix extensions are enabled of course.
>
>We could. But that is a windowism where ':' is a reserved character
>but which is not a reserved character in unixens.
>For example:
>You have the file "foo" with stream "bar" and you have another normal
>file "foo:bar"
>Which one does open("foo:bar") give you?
>
>The openat/... semantics that solaris uses provides an elegant and
>unambiguous semantics for it.
>You want to open stream bar on file foo?
>1, fh = open("foo")
>2, sh = openatf(h, "bar")
>
>There are at least two non-windows related filesystems that support
>something similar to ADS,
>solaris filesystem and apples filesystem(s) so it would be nice to
>have a neutral API where an application can use the same
>code to access streams be they cifs/ntfs/solarisfs/applefs/...other...
>
>Steve, I think this would be a good discussion topic for vfs meetings.
>Is it desirable to bless an api in the vfs to do alternate data
>streams?
>There are at least 4 filesystems that provide this feature, 3 of which
>are still very popular and common today.
>
>One approach would be to mimic the interface that solaris provides
>with openatfile-fd, "stream-name")

Solaris is dead, dead, dead. We should not resurrect the
warts of that thing in Linux.

>But that would not just be a filesystem change but also a VFS change
>since it would suddenly accept passing a file-fd as argument
>as a valid option (for those filesystems that have signalled
>alternative stream support?)
>while the vfs currently only allows openat() on a directory-fd.

I never thought I'd be calling on Christolph Hellwig
to squash such a horror before it emerges, but I'm
  CC:ing him on this email in the hope that he will :-).

>ADS as a concept is really powerful and could be enormously useful as
>way to attach metadata to a file object in a standardized way.
>There are very many use-cases where having a file that embedded both
>the executable as well as various other types of data but still be
>able to treat it as a single self-contained file from an end-user
>perspective.

Please give real examples of something for which this
is *essential*. Not "could be.. useful".

Hard mode. Windows has yet to find such an example :-).

One more datapoint: "still be able to treat it as a single self-contained
file from an end-user perspective." - please enumerate
every single tool and archiving program that will need
to be changed to treat a file containing alternate data
streams as "a single self-contained file".

>This should be discussed and we should probe the vfs folks about what
>they think about it.

I hope they just say no :-).