All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Walker <awalker@ixsystems.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Jeremy Allison <jra@samba.org>, Steve French <smfrench@gmail.com>,
	samba-technical <samba-technical@lists.samba.org>,
	CIFS <linux-cifs@vger.kernel.org>
Subject: Re: Displaying streams as xattrs
Date: Mon, 22 May 2023 21:23:32 -0500	[thread overview]
Message-ID: <CAB5c7xqcwn6a_D=OwyKDMRgEiKEnGHeubwafVU09o34cQ2G30A@mail.gmail.com> (raw)
In-Reply-To: <CAN05THRnHcZtTMLxUSCYQXULVHiOXVYDU9TRy9K+_wBQQ1CFAw@mail.gmail.com>

On Mon, May 22, 2023 at 8:00 PM ronnie sahlberg via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> Yeah, I don't think we should surface these as xattrs.
> Xattrs are already way too small for most of the usecases of ADS on
> windows (file metadata for explorer etc)
> and they are also just an atomic blob and not a proper filedescriptor.
> Since ADS is still just a file, any application that in the future
> will use ADS features should only do so via
> a proper filedescriptors, where it is possible to
> seek/read/write/truncate/...  so IMHO we shouldn't offer them an
> alternative but inferior API. Because they might mistakenly start to use it. :-(
>
> There are no real applications, yet, for linux that uses ADS but there
> are many that potentially could use ADS or
> become ADS aware. GUI Filebrowsers would be a nice usecase. As would
> making 'cp', 'mv', 'tar', 'rsync', ... ADS aware.
>
> So let's not do it with xattrs.
> No one needs/asks for this right now so it would be code we will have
> to maintain but has no users.
>
>
> What we should do though is think about and talk with the NTFS folks
> so that we make sure our aims and APIs will align with the plans they
> have.
> And once we have multiple filesystems supporting it (cifs.ko and ntfs)
> then we can start thinking about how to encourage external users and
> applications to use it.
> There are really nice use-cases for ADS where one can store additional
> metadata within the "file" itself.
>
> regards
> ronnie s
>
> On Tue, 23 May 2023 at 02:21, Jeremy Allison <jra@samba.org> wrote:
> >
> > 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@gmail.com> 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.
>

Solaris / Illumos had a neat feature where you could say openat(fd,
O_RDWR | O_XATTR) to open a stream on ZFS and then do normal file IO
to the stream (pread, pwrite, etc).

  reply	other threads:[~2023-05-23  2:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  2:08 Displaying streams as xattrs Steve French
2023-05-22  4:33 ` ronnie sahlberg
2023-05-22  6:39   ` Steve French
2023-05-22 14:41     ` ronnie sahlberg
2023-05-22 16:21     ` Jeremy Allison
2023-05-23  0:59       ` ronnie sahlberg
2023-05-23  2:23         ` Andrew Walker [this message]
2023-05-23 16:25         ` Jeremy Allison
2023-05-23 21:44           ` ronnie sahlberg
2023-05-23 22:34             ` Jeremy Allison
2023-05-25 10:57               ` ronnie sahlberg
2023-05-25 16:15                 ` Jeremy Allison
2023-05-26  2:39                   ` ronnie sahlberg
2023-05-26 16:20                     ` Jeremy Allison
2023-05-25  9:39       ` Björn JACKE
2023-05-25 10:49         ` ronnie sahlberg
2023-05-25 16:22           ` Jeremy Allison
2023-05-25 20:11             ` Steve French
2023-05-25 20:22               ` Jeremy Allison
2023-05-25 22:14                 ` Björn JACKE
2023-05-25 23:50                   ` Steve French
2023-05-26  2:16                     ` ronnie sahlberg
2023-05-26 16:03                     ` Björn JACKE
     [not found]                       ` <CAH2r5muD89QUcaqWNQy5NUwyji9CinN_5kGcfFSQAbpJP5gn+A@mail.gmail.com>
2023-05-27  1:50                         ` Steve French
2023-05-30  7:26                       ` Michael Weiser
2023-05-22 15:36 ` Andrew Walker

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='CAB5c7xqcwn6a_D=OwyKDMRgEiKEnGHeubwafVU09o34cQ2G30A@mail.gmail.com' \
    --to=awalker@ixsystems.com \
    --cc=jra@samba.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=samba-technical@lists.samba.org \
    --cc=smfrench@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.