[Top][All Lists]

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

Re: fstatat + AT_NO_AUTOMOUNT

From: Pádraig Brady
Subject: Re: fstatat + AT_NO_AUTOMOUNT
Date: Mon, 7 Mar 2022 23:23:48 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0

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.


* 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.

reply via email to

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