[349] in Info-AFS_Redistribution
[zalewk@rpi.edu: Major problems with TeX-3.14]
daemon@ATHENA.MIT.EDU (Mike Shaddock)
Thu Oct 17 09:28:59 1991
Date: Thu, 17 Oct 91 07:28:36 -0400
From: Mike Shaddock <shaddock@unx.sas.com>
To: info-afs@transarc.com
In-Reply-To: <9110161826.AA07552@cobra.unx.sas.com> "snornb@unx.sas.com"
To: info-afs@transarc.com
Subject: Major problems with TeX-3.14
Date: Tue, 15 Oct 91 17:13:59 -0400
From: zalewk@rpi.edu
At RPI, we have recently installed TeX, Version 3.14 into AFS
space. I had orginally built it in NFS space, after FTPing the
sources from byron. TeX, LaTeX, et al worked fine on all the
architectures I built it for, which include SUN4's, SUN3's,
RS/6000's, and AIX/370.
However, upon moving everything into AFS space, strange things
started happening. Users reported getting "<directory>: Permission
Denied" messages, where <directory> was some directory in AFS
space, and NOT one of the directories that TeX uses (ie. fonts,
inputs, formats, etc.).
I myself ran into this problem yesterday, and it is reproducible on
all architectures. I ran /campus/text/tex/3.14/sun4c_41/bin/latex
(which is in AFS space) from my home directory (/home/06/zalewk,
also in AFS space). I got an error message "boburj: Permission
denied", and then my prompt back. No TeX banner message, or
anything. The trace output shows that something is causing TeX to
traverse up from my current directory to the root partition.
Because it found a depermitted directory along the way
(/home/06/boburj), it stopped. I have included the trace output
below.
Now, since TeX worked fine in NFS space, I would assume that there
is some AFS call which is causing either TeX, or the loader, to
traverse unnecessary directories. This causes TeX to take a VERY
long time to startup, if it can make it thru all the directories.
If not, then it can't even be run. I think this is enough
information to go on for now. Since our /campus tree is in AFS, if
you get the rpi.edu tree, you can look in /campus/text/tex/3.14
yourself if you think it will help. I will also try to provide any
other information you might need to know. This is a high priority
problem, since TeX is now in production here, and quite a few users
are depending on it. Thanks for any help you can give.
It looks like the problem is that ld.so is doing a getcwd(), which
has to walk up the tree to / to figure out where it is. While it is
doing this it encounters a directory that does not have lookup rights
enabled for anyone, which causes the lstat() to fail, something which
normally doesn't happen on a standard UNIX filesystem. It looks like
Sun's version of getcwd() actually lstat()s each directory instead of
using the information from getdents().
If this analysis is correct, then my question is, should lstat() fail
in this case? Operations which read the directory and/or examine the
ACL are clearly disallowed by not having lookup rights, yet lstat() is
doing neither of these (admittedly it will get the UNIX mode bits, but
that's not the same).
----
Mike Shaddock SAS Institute, Inc.
shaddock@unx.sas.com (919) 677-8000
