Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?

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

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux