[list abuse] bug in /bin/csh and /usr/local/bin/tcsh?

[Mark Borges <mdb@xxxxxxxxxxxx>]

This is certainly not a zsh bug, but since this list has many members
who know far more about the internals of shells than I, I thought it
would be a good forum.

Q: Why do /bin/csh and /usr/local/bin/tcsh, as part of their startup
   process, do an lstat of every directory in the root partition where
   the shell was invoked?

For instance,

  $ truss /bin/csh -c 'echo foobar' |& grep /archive
  lstat("./../archive", 0xEFFFC400)               = 0
  $ truss /usr/local/bin/tcsh -c 'echo foobar' |& grep /archive 
  lstat("../archive", 0xEFFFE308)                 = 0
  $ truss /bin/sh -c 'echo foobar' |& grep /archive 
  $ truss /usr/local/bin/zsh -c 'echo foobar' |& grep /archive 
  $ truss /bin/ksh -c 'echo foobar' |& grep /archive 
  $ uname -a
  SunOS solberg 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-2
  $

(Note that zsh, sh, and ksh do not do the lstat. archive is a mount
point in / for an NFS mounted partition. The script was invoked in a
subdirectory of /).

Ordinarily, this is not a big problem. But, one of our users has many
/bin/csh scripts in his crontab, and when /archive is inaccessible
(it's a jukebox filesystem that is *very* flaky) his /bin/csh cronjobs
hang and fail to execute.

As a potential workaround, we've NFS mounted this volume read-only and
soft-mounted (it was rw and hard mounted) in the hope that the shell
will at least start up and execute the script (which has nothing to do
with /archive). Or will this fail, too?

Any comments or other suggested work-arounds are most welcome. I've
tried "don't write scripts in /bin/csh!", but that falls on deaf ears
;-).

-- 
  -mb-