coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fstatat + AT_NO_AUTOMOUNT


From: Paul Eggert
Subject: Re: fstatat + AT_NO_AUTOMOUNT
Date: Mon, 7 Mar 2022 09:11:33 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 3/7/22 07:02, Pádraig Brady wrote:
When looking into https://bugs.gnu.org/54286
which discussed statx + AT_NO_AUTOMOUNT,
I was wondering about the fstatat changes in
https://github.com/coreutils/coreutils/commit/571f63f50
and whether some of those should also specify AT_NO_AUTOMOUNT?

I'm a bit lost, as I see no mention of fstatat in that commit.

I was not aware of AT_NO_AUTOMOUNT until now, and am surprised about it. POSIX says that stat(f,s) is supposed to be equivalent to fstatat(AT_FDCWD,f,s,0). But if I understand things correctly, this isn't true on GNU/Linux: you must pass AT_NO_AUTOMOUNT instead of 0. I assume that this departure from POSIX was intentional, but even so it's pretty confusing. Could you explain why AT_NO_AUTOMOUNT wasn't made the default for fstatat?

I suppose we first need to audit all of Gnulib's uses of fstatat and statx to see whether they need AT_NO_AUTOMOUNT added. Once we're done with that we can turn to Coreutils.

For example, what about the calls to fstatat in gnulib/lib/openat.h? Are statat and lstatat intended as convenient aliases for fstatat, or as directory-fd extensions to stat and lstat? If the former, they should be left alone; if the latter, they need AT_NO_AUTOMOUNT. Or perhaps it would be better to eliminate them and replace them with calls to fstatat, since we'll need to decide on a call-by-call basis anyway.

Another example: what about the fstatat call in gnulib/lib/fchmodat.c? I suppose we should not add AT_NO_AUTOMOUNT there, under the theory that GNU/Linux faccessat does not do the equivalent of AT_NO_AUTOMOUNT. Is that right?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]