Ian Kent <raven@xxxxxxxxxx> writes: > On Tue, 2011-09-06 at 10:09 +0200, Miklos Szeredi wrote: >> Ian Kent <raven@xxxxxxxxxx> writes: >> >> > On Mon, 2011-09-05 at 19:02 +0200, Miklos Szeredi wrote: >> >> >> >> If automounting on lstat(2) is the correct behavior (is it? why?) then at >> >> least it should be enabled by a global switch or mount option, IMO. >> > >> > Ideally we wouldn't need to take special precautions for these >> > operations at all but we can't, especially for GUI environments that >> > constantly scan file systems on mount/umount activity. >> > >> > Historically for autofs, neither stat(2) or lstat(2) would trigger a >> > mount. With the current implementation stat(2) now does but lstat(2) >> > doesn't which is a step in the right direction IMHO. So, I recommend we >> > continue to encourage user space to make the needed changes so we >> > continue to move in the right direction, and yes, I acknowledge it is a >> > pain but it'll never get done otherwise. >> >> I'm not quite convinced. What's the advantage of triggering automount >> on stat(2)? > > You get the information of the directory of the mounted fs and for many > peoples purposes automounting should be transparent so that would be > best. The same is true for lstat(2). > >> >> Has anybody complained that stat(2) on the mountpoint doesn't cause an >> automount? > > Yes, based on the reasoning above. Would any of those complaints go away if stat(2) did cause an automount and lstat(2) didn't? With AT_NO_AUTOMOUNT I can agree with, that's a flag specifically about not automounting. Unlike AT_SYMLINK_NOFOLLOW which is about following symlinks and hasn't got a lot to do with automounts. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
