All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: David Howells <dhowells@redhat.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: Clarification of statx->attributes_mask meaning?
Date: Tue, 1 Dec 2020 10:39:27 -0500	[thread overview]
Message-ID: <20201201153927.GL5364@mit.edu> (raw)
In-Reply-To: <f259c5ee-7465-890a-3749-44eb8be0f8cf@sandeen.net>

On Mon, Nov 30, 2020 at 09:37:29PM -0600, Eric Sandeen wrote:
> > We should be really clear how applications are supposed to use the
> > attributes_mask.  Does it mean that they will always be able to set a
> > flag which is set in the attribute mask?  That can't be right, since
> > there will be a number of flags that may have some more complex checks
> > (you must be root, or the file must be zero length, etc.)  I'm a bit
> > unclear about what are the useful ways in which an attribute_mask can
> > be used by a userspace application --- and under what circumstances
> > might an application be depending on the semantics of attribute_mask,
> > so we don't accidentally give them an opportunity to complain and
> > whine, thus opening ourselves to another O_PONIES controversy.
> 
> Hah, indeed.
> 
> Sorry if I've over-complicated this, I'm honestly just confused now.

Yeah, I'm honestly confused too how applications can use the
attributes mask, too.

Presumably there is some case where the flag not being set *and* the
file system can support that attribute, that the application could
infer something interesting.  I just can't figure out what that case
would be.

Yes, I see your pointer to Cristoph's question on this very issue back
in April 2017.  Pity it was never answered, at least that was archived
on lore.

					- Ted


  parent reply	other threads:[~2020-12-01 15:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 19:19 Clarification of statx->attributes_mask meaning? Eric Sandeen
2020-11-25 21:25 ` Darrick J. Wong
2020-11-25 21:42   ` Eric Sandeen
2020-11-25 21:50 ` David Howells
2020-11-30 23:29   ` Eric Sandeen
2020-12-01  3:20     ` Theodore Y. Ts'o
2020-12-01  3:37       ` Eric Sandeen
2020-12-01  3:50         ` Eric Sandeen
2020-12-01 15:39         ` Theodore Y. Ts'o [this message]
2020-12-01 16:25           ` Miklos Szeredi

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=20201201153927.GL5364@mit.edu \
    --to=tytso@mit.edu \
    --cc=darrick.wong@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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.