Re: fstatat + AT_NO_AUTOMOUNT

[Pádraig Brady]

On 07/03/2022 22:36, Paul Eggert wrote:
> On 3/7/22 13:56, Pádraig Brady wrote:
> > $ git show 571f63f50 | grep -B3 fstatat
>
> Ah, I now see the problem: I suppressed some of GitHub's JavaScript code
> when looking at the URL you sent. I'll have to remember not to do that.

Or add a .patch suffix to the URL

> After thinking about it a bit more, how about the following idea?
>
> * Normally, do not use AT_NO_AUTOMOUNT.
>
> * If a file is known to exist but its type is not known, it's OK to use
> fstatat with AT_NO_AUTOMOUNT to determine the file's type, under the
> theory that mounting should merely replace directories with directories
> and so won't change the type, so that AT_NO_AUTOMOUNT is merely an
> optimization here. A use case might be fts.c wanting to know whether a
> directory entry with type DT_UNKNOWN is itself a directory.

Right.

> * I don't yet see any other use for AT_NO_AUTOMOUNT.

Apart from the ls(1) and stat(1) cases previously mentioned I presume.
I'll push those patches now.

> 'cp -x' is an example where we can't use AT_NO_AUTOMOUNT, since cp needs
> to read the source file (not just stat it) and so we want the automount
> so that the stat result is consistent with the other accesses.
>
> 'du -x' is a more-plausible use of AT_NO_AUTOMOUNT but I don't see how
> it could work correctly.
>
> 'df' likely needs to use both fstatat and statvfs and the latter lacks
> AT_NO_AUTOMOUNT, which means the former shouldn't use AT_NO_AUTOMOUNT.

Yes I agree with the above analysis.

thanks for the consideration.
Pádraig