Xref: utzoo comp.unix.i386:6706 comp.unix.wizards:22831 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!haven!decuac!grebyn!media!rmf From: rmf@media.uucp (Roger Fujii) Newsgroups: comp.unix.i386,comp.unix.wizards Subject: Re: i386 unix with NFS - getcwd() & /bin/pwd inode problem Message-ID: <1990Jul11.050856.18877@media.uucp> Date: 11 Jul 90 05:08:56 GMT References: <1990Jul9.142023.17830@ico.isc.com> Distribution: na Organization: Media Cybernetics, Inc. Lines: 29 dougm@ico.isc.com (Doug McCallum) writes: >In article denny@tss.com (Denny Page) writes: >>When you are in a directory which is mounted via nfs, and the inode of >>the current directory is > 65535 (such as on a sun), /bin/pwd reports >>"read error in .." Getcwd() uses /bin/pwd to do its work, and as such >>doesn't function. Is anyone aware of a fix or a work around for this? >This is a difficult problem to work around. AT&T changed internal inode >numbers to long's but left the "stat" system call version of the inode >number a short. Just changing it and rebuilding the world would solve >the problem but would then break every application that comes from >somewhere else. Fixes have to be made such that they are compatible >with previous systems and systems from other vendors. I expect that >some type of fix will be made in a future release of our (ISC) version >once we have one which will let the binary work on other systems that >don't have the fix. Ahhh.... Someone else found this too.... Solution: 1) Fix /bin/pwd (see the bsd getpwd). I have it somewhere.... Unfortunatly, there is a lose if there just happens to be two files in the same directory with the inode numbers separated by 2^16 or greater. 2) Patch /bin/sh to disable the builtin pwd (change it to owd) -- Roger Fujii - Media Cybernetics Phone: (301)495-3305 Internet: rmf%media@uunet.uu.net UUCP: {uunet,hqda-ai}!media!rmf