[Top][All Lists]

[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 11:09:32 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

On 3/7/22 09:33, Pádraig Brady wrote:
On 07/03/2022 17:11, Paul Eggert wrote:
On 3/7/22 07:02, Pádraig Brady wrote:
When looking into
which discussed statx + AT_NO_AUTOMOUNT,
I was wondering about the fstatat changes in
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.

That commit replaced some stat() calls with fstatat().

How did it do that? Sorry, I'm still lost: the commit doesn't say "fstatat" anywhere.

Attached is an adjustment for ln in coreutils at least.

I see a problem with that change. Suppose D does not exist, but is an on-demand directory such as used for automounter indirect maps. Then "ln -f S D" will use fstatat with AT_NO_AUTOMOUNT on D, and will assume that D does not exist.

I can see where AT_NO_AUTOMOUNT might be useful for commands like 'find' that do mass lstats or commands like 'df' designed to access mountpoints, but why is it useful for 'ln'? It seems like it'd be more trouble than it's worth.

I see unlinkat() uses lstatat(),
and in that context it would be better to specify AT_NO_AUTOMOUNT
I think since we're operating on the dir not the file itself.

If it weren't for on-demand directories I would agree with AT_NO_AUTOMOUNT there, but I think the reason would be different. Ordinarily mount points are directories, and so automounting replaces one directory with another. Since gnulib/lib/unlinkat.c is trying to determine whether it's unlinking a directory, mounting won't change that, so there's no point to mounting, and AT_NO_AUTOMOUNT is a performance win there. (Although it's possible to mount onto a non-directory, this is bad practice and I don't think we need to worry about that.)

Unfortunately, on-demand directories mess up the calculation, since they replace nonexistent files with directories. So it appears that AT_NO_AUTOMOUNT would not be an acceptable optimization in gnulib/lib/unlinkat.c, since it would mess up in that case.

Also agreed that eliminating these aliases
would avoid at least this particular ambiguity.

Yes, that looks like a win (unfortunately, as the aliases do make things shorter; but they're too confusing now).

reply via email to

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