On Mon, 12 Jul 2004, Jim Carter wrote: > > Now here's what I'm thinking: with Linux autofs the inode returned by stat > isn't quite right, or changes at just the wrong time, or something like > that. If the pwd algorithm can't find the target, the behavior is > implementation defined, and a very likely behavior is to skip that > directory component with no error message. I know that the pwd command is > implemented internally in csh and tcsh -- it just prints $pwd -- and I > wouldn't be surprised if the shell does the research with its own code > rather than forking /bin/pwd. > > So that's a possible explanation of why (t)csh shows the behavior and > (ba)sh doesn't. Hope this helps. > > I wonder what would break if autofs were super-smart and returned the inode > number of what was on the mount point, as long as it was still mounted. It > would save a bunch of otherwise wasted NFS traffic and would avoid the kind > of hangs that troubled us (and still trouble us) when a server goes down. > But lying about inode numbers probably has baleful consequences in some > bizarre circumstance. Like keeping use counts up to date.
Don't think the original problem was as colorful as that. In this case I think that the source of this original problem was an error in the daemon wrt directory create/remove as well as some bouncing around creating/removing them. That approach seemed to fix it. Ian _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
