On Thu, 25 May 2023 at 19:40, Björn JACKE via samba-technical
<samba-technical@xxxxxxxxxxxxxxx> wrote:
>
> On 2023-05-22 at 09:21 -0700 Jeremy Allison via samba-technical sent off:
> > On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
> > > On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> > > <ronniesahlberg@xxxxxxxxx> wrote:
> > > >
> > > > A problem we have with xattrs today is that we use EAs and these are
> > > > case insensitive.
> > > > Even worse I think windows may also convert the names to uppercase :-(
> > > > And there is no way to change it in the registry :-(
> > >
> > > But for alternate data streams if we allowed them to be retrieved via xattrs,
> > > would case sensitivity matter? Alternate data streams IIRC are already
> > > case preserving. Presumably the more common case is for a Linux user
> > > to read (or backup) an existing alternate data stream (which are usually
> > > created by Windows so case sensitivity would not be relevant).
> >
> > Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
> > confusion and disaster IMHO.
> >
> > They really are different things. No good will come of trying to mix
> > the two into one client namespace.
> >
>
> 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")
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.
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.
This should be discussed and we should probe the vfs folks about what
they think about it.
regards
ronnie s
>
> Björn
>
