linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Eric Biggers <ebiggers@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	ronnie sahlberg <ronniesahlberg@gmail.com>,
	Chuck Lever <chuck.lever@oracle.com>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Steve French <sfrench@samba.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] fs: Add FS_XFLAG_COMPRESSED & FS_XFLAG_ENCRYPTED for FS_IOC_FS[GS]ETXATTR API
Date: Wed, 19 Feb 2025 00:06:43 +0100	[thread overview]
Message-ID: <20250218230643.fuc546ntkq3nnnom@pali> (raw)
In-Reply-To: <Z7UQHL5odYOBqAvo@dread.disaster.area>

On Wednesday 19 February 2025 09:56:28 Dave Chinner wrote:
> On Tue, Feb 18, 2025 at 08:27:01PM +0100, Pali Rohár wrote:
> > On Tuesday 18 February 2025 10:13:46 Amir Goldstein wrote:
> > > > and there is no need for whacky field
> > > > masks or anything like that. All it needs is a single bit to
> > > > indicate if the windows attributes are supported, and they are all
> > > > implemented as normal FS_XFLAG fields in the fsx_xflags field.
> > > >
> > 
> > If MS adds 3 new attributes then we cannot add them to fsx_xflags
> > because all bits of fsx_xflags would be exhausted.
> 
> And then we can discuss how to extend the fsxattr structure to
> implement more flags.
> 
> In this scenario we'd also need another flag bit to indicate that
> there is a second set of windows attributes that are supported...
> 
> i.e. this isn't a problem we need to solve right now.

Ok, that is possible solution for now.

> > Just having only one FS_XFLAGS_HAS_WIN_ATTRS flag for determining windows
> > attribute support is not enough, as it would not say anything useful for
> > userspace.
> 
> IDGI.
> 
> That flag is only needed to tell userspace "this filesystem supports
> windows attributes". Then GET will return the ones that are set,
> and SET will return -EINVAL for those that it can't set (e.g.
> compress, encrypt). What more does userspace actually need?

Userspace backup utility would like to backup as many attributes as
possible by what is supported by the target filesystem. What would such
utility would do if the target filesystem supports only HIDDEN
attribute, and source file has all windows attributes set? It would be
needed to issue 2*N syscalls in the worst case to set attributes.
It would be combination of GET+SET for every one windows attribute
because userspace does not know what is supported and what not.

IMHO this is suboptimal. If filesystem would provide API to get list of
supported attributes then this can be done by 2-3 syscalls.

  reply	other threads:[~2025-02-18 23:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-16 16:40 [RFC PATCH 0/4] fs: Add support for Windows file attributes Pali Rohár
2025-02-16 16:40 ` [RFC PATCH 1/4] fs: Add FS_XFLAG_COMPRESSED & FS_XFLAG_ENCRYPTED for FS_IOC_FS[GS]ETXATTR API Pali Rohár
2025-02-16 18:34   ` Eric Biggers
2025-02-16 18:49     ` Pali Rohár
2025-02-16 20:17     ` Amir Goldstein
2025-02-16 20:24       ` Pali Rohár
2025-02-16 20:43         ` Amir Goldstein
2025-02-16 21:17           ` Pali Rohár
2025-02-17  8:27             ` Amir Goldstein
2025-02-18  1:33           ` Dave Chinner
2025-02-18  9:13             ` Amir Goldstein
2025-02-18 19:27               ` Pali Rohár
2025-02-18 22:56                 ` Dave Chinner
2025-02-18 23:06                   ` Pali Rohár [this message]
2025-02-19  7:55                     ` Amir Goldstein
2025-02-21 16:34                       ` Theodore Ts'o
2025-02-21 17:11                         ` Amir Goldstein
2025-02-25  5:41                           ` Dave Chinner
2025-02-25 20:14                             ` Pali Rohár
2025-02-21 18:55                         ` Andreas Dilger
2025-02-25  3:42                         ` Dave Chinner
2025-02-18 22:45               ` Dave Chinner
2025-02-16 16:40 ` [RFC PATCH 2/4] fs: Extend FS_IOC_FS[GS]ETXATTR API for Windows attributes Pali Rohár
2025-02-16 19:55   ` Amir Goldstein
2025-02-16 20:01     ` Pali Rohár
2025-02-16 20:34       ` Amir Goldstein
2025-02-16 21:01         ` Pali Rohár
2025-02-16 16:40 ` [RFC PATCH 3/4] fs: Implement support for fsx_xflags_mask, fsx_xflags2 and fsx_xflags2_mask into vfs Pali Rohár
2025-02-21 18:24   ` Theodore Ts'o
2025-02-25 20:07     ` Pali Rohár
2025-02-16 16:40 ` [RFC PATCH 4/4] cifs: Implement FS_IOC_FS[GS]ETXATTR API for Windows attributes Pali Rohár
2025-02-16 20:21   ` Amir Goldstein
2025-02-16 20:25     ` Pali Rohár

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=20250218230643.fuc546ntkq3nnnom@pali \
    --to=pali@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=sfrench@samba.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).