Paul Szabo wrote:
James,
Hmm... It would not descend into just-now-changed automounts (and it may
not be able to get back out of them), but it should be able to traverse
reasonably long-lived mounts.
The problem is though that when you chdir() into an automount mount
point, automount aill automatically mount it for you. Hence if an
automount filesystem wasn't already mounted, if you chdir() into it it
immediately becomes a "just-now-changed" mount point. That's the
essensce of the problem I am trying to solve.
I think find should never cause an automount to "trigger" and cause it to
be mounted. It is OK to traverse if it was mounted to start with; is surely
not OK to traverse if it wasn't already mounted. Maybe your problem is
sidestepped by this principle?
I strongly disagree with this principle. Automount points (at least on
Solaris) are supposed to be transparent to the user; just an
implementation optimization over having them permanently mounted.
[Right now cannot think of examples where find causing automounts to
trigger would be an obvious security or performance issue.]
To prevent find from causing an automount to trigger, maybe you could
somehow detect the presence of the mount point, check its status, and
(after a warning) not descend if it wasn't mounted. [I use the Debian
autofs package; this uses a normally empty directory, which is populated
with mounted directories when in use. Are we talking about the short time
between the mkdir of the mountpoint and the mount?]
Linux automounters work differently. I've never quite understood the
various implementations, but the ones that use symlinks in the
implementation are quite horrible, since the symlinks leak out and
affect user programs. Solaris' automounter is really quite
unobtrusive, except for programs like `find' that check the dev and
inode for constancy.
Martin
