Re: Changes to the filesystem while find is running - comments?

[Martin Buchholz <Martin.Buchholz () Sun COM>]

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