On 2020-04-11, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Sat, Apr 11, 2020 at 04:02:36PM +1000, Aleksa Sarai wrote: > > On 2020-04-11, Askar Safin <safinaskar@xxxxxxx> 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. I wasn't suggesting that RESOLVE_NO_AUTOMOUNTS would unmask whatever is on the underlying filesystem -- I agree that would be completely insane. It would just give you -EXDEV (or perhaps -EREMOTE) if you walk into an automount (the same logic as with the other RESOLVE_NO_* flags). We could make it -ENOENT if you prefer, but that means userspace can't tell the difference between it hitting an automount and the target actually not existing. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
