From: Al Viro <viro@zeniv.linux.org.uk>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Askar Safin <safinaskar@mail.ru>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?
Date: Sat, 11 Apr 2020 07:45:30 +0100 [thread overview]
Message-ID: <20200411064530.GL23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200411060236.swlgw6ymzikgcqxl@yavin.dot.cyphar.com>
On Sat, Apr 11, 2020 at 04:02:36PM +1000, Aleksa Sarai wrote:
> On 2020-04-11, Askar Safin <safinaskar@mail.ru> wrote:
> > What about adding stat's AT_NO_AUTOMOUNT analogue to openat2?
>
> There isn't one. I did intend to add RESOLVE_NO_AUTOMOUNTS after openat2
> was merged -- it's even mentioned in the commit message -- but I haven't
> gotten around to it yet. The reason it wasn't added from the outset was
> that I wasn't sure if adding it would be as simple as the other
> RESOLVE_* flags.
>
> Note that like all RESOLVE_* flags, it would apply to all components so
> it wouldn't be truly analogous with AT_NO_AUTOMOUNT (though as I've
> discussed at length on this ML, most people do actually want the
> RESOLVE_* semantics). But you can emulate the AT_* ones much more easily
> with RESOLVE_* than vice-versa).
Er... Not triggering automount on anything but the last component means
failing with ENOENT. *All* automount points are empty and are bloody
well going to remain such, as far as I'm concerned.
next prev parent reply other threads:[~2020-04-11 6:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 22:41 What about adding AT_NO_AUTOMOUNT analogue to openat2? Askar Safin
2020-04-11 6:02 ` Aleksa Sarai
2020-04-11 6:45 ` Al Viro [this message]
2020-04-11 7:07 ` Aleksa Sarai
2020-04-11 10:51 ` Florian Weimer
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=20200411064530.GL23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=cyphar@cyphar.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=safinaskar@mail.ru \
/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.