rich@jolnet.UUCP (Rich Andrews) (08/01/88)
When I am in /usr/lib and execute a find command such as "find . -print" it gets to /usr/lib/uucp and then it fails with a stat() failed /usr/lib/uucp/cd_text. This is not the only file that this happens to. It also happens to some of my /usr/lib/*.a files and to some of my F77 libs and pascal files. Fsck reports all is ok and the files are readable. Any ideas? rich andrews -- Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95. Simply send $19.95 (in Alterian dollars) to ...ihnp4!killer!jolnet!rich.
hd@mh_co2.mh.nl (Theo Hardendood) (08/01/88)
From article <673@jolnet.UUCP>, by rich@jolnet.UUCP (Rich Andrews): > When I am in /usr/lib and execute a find command such as > "find . -print" it gets to /usr/lib/uucp and then it fails > with a stat() failed /usr/lib/uucp/cd_text. > (...) > Fsck reports all is ok and the files are readable. > Any ideas? Yes, we had the same problem on one of our own machines. The problem was a corrupt parent directory. As you will probably now, fsck does not check the contents of files so it will report no errors. Try checking the file system with 'ncheck -a <file-system>'. If this doesn't help, examine /usr, /usr/lib and /usr/lib/uucp with 'ls -il' or 'od -c <directory-name>'. Regards, Theo Hardendood Theo Hardendood hd@mh.nl via european backbone (mcvax) Multihouse NV, Gouda - The Netherlands uucp: ..!mcvax!mh.nl!hd "A conclusion is simply the place where someone got tired of thinking."
kluft@hpcupt1.HP.COM (Ian Kluft) (08/02/88)
rich@jolnet.UUCP (Rich Andrews) writes: > When I am in /usr/lib and execute a find command such as > "find . -print" it gets to /usr/lib/uucp and then it fails > with a stat() failed /usr/lib/uucp/cd_text. > > This is not the only file that this happens to. It also > happens to some of my /usr/lib/*.a files and to some > of my F77 libs and pascal files. > > Fsck reports all is ok and the files are readable. > > Any ideas? Find's access is limited to what you as a user can normally see. Under root, you shouldn't have such problems. The big question is: were you root when this problem occurred? If you were, see stat(2) for any quirks your system may have which might return an error to 'find'. ------------------------------------------------------------------ Ian Kluft RAS Lab UUCP: hplabs!hprasor!kluft HP Systems Technology Division ARPA: kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------------
banton@hpirs.HP.COM (Butch Anton) (08/02/88)
rich@jolnet.UUCP (Rich Andrews) writes: > When I am in /usr/lib and execute a find command such as > "find . -print" it gets to /usr/lib/uucp and then it fails > with a stat() failed /usr/lib/uucp/cd_text. > > This is not the only file that this happens to. It also > happens to some of my /usr/lib/*.a files and to some > of my F77 libs and pascal files. > > Fsck reports all is ok and the files are readable. > > Any ideas? If other suggestions fail, it may be a simple case of cd_text being hosed. My suggestions are as follows: 1) copy cd_text cd_text.temp 2) rm cd_text 3) mv cd_text.temp cd_text That should give you a (resonably) clean copy of cd_text. Hopefully, things will return to normal. Please note: This may or may not work, depending on how hosed the file is, if it's hosed at all. It also assumes that you'll be able to get a clean copy from cd_text; this may not be possible. I know these suggestions sound a little bit iffy, and that's 'cause they are, but it's worked for me in the past. -Butch
rich@jolnet.UUCP (Rich Andrews) (08/03/88)
In article <3920006@hpirs.HP.COM> banton@hpirs.HP.COM (Butch Anton) writes: >rich@jolnet.UUCP (Rich Andrews) writes: > When I am in /usr/lib and execute a find command such as > "find . -print" it gets to /usr/lib/uucp and then it fails > with a stat() failed /usr/lib/uucp/cd_text. > > This is not the only file that this happens to. It also > happens to some of my /usr/lib/*.a files and to some > of my F77 libs and pascal files. > > Fsck reports all is ok and the files are readable. > > Any ideas? If other suggestions fail, it may be a simple case of cd_text being hosed. My suggestions are as follows: 1) copy cd_text cd_text.temp 2) rm cd_text 3) mv cd_text.temp cd_text That should give you a (resonably) clean copy of cd_text. Hopefully, things will return to normal. Please note: This may or may not work, depending on how hosed the file is, if it's hosed at all. It also assumes that you'll be able to get a clean copy from cd_text; this may not be possible. I know these suggestions sound a little bit iffy, and that's 'cause they are, but it's worked for me in the past. -Butch I have done that and if you want, I will post a listing of all files that fail during find. It is incredible! Last night i copied all the files in /usr /lib into a different directory and then copied them back to no avail. One suggestion was to use tar to archive the files but it failed to archive the files that find fails on. Cpio is next. I think that the next call will be to AT&T. Maybe they have a fix. rich andrews -- Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95. Simply send $19.95 (in Alterian dollars) to ...ihnp4!killer!jolnet!rich.
asa@unisoft.UUCP (Asa Romberger) (08/03/88)
In article <3920006@hpirs.HP.COM> banton@hpirs.HP.COM (Butch Anton) writes: >rich@jolnet.UUCP (Rich Andrews) writes: > >> When I am in /usr/lib and execute a find command such as >> "find . -print" it gets to /usr/lib/uucp and then it fails >> with a stat() failed /usr/lib/uucp/cd_text. I have seen this sort of behaviour also. For me it has always been one simple thing. It turns out the find does not keep track of full path names of directories that it is searching. It changes down into a new directory and then expects to be able to change back to the higher directory by doing a cd .. Under clean 5.* type file systems that do not have symbolic links, this should always work. The two cases that cause problems are symbolic links and bad directory links. Suppose I have cheated and have created an /etc/link to a directory. eg: original is /mnt/mine/a link is from /mnt/yours/a What I have is: /mnt/mine/a points to the directory /mnt/yours/a points to the directory /mnt/mine/a/.. points to /mnt/mine /mnt/yours/a/.. points to /mnt/mine Suppose I am doing a find in /mnt/yours. Find finds the directory a and does a cd to it. When it is complete, it does a cd .. and gets back to /mnt/mine. It gets very confused and starts telling you about not being able to find files that are in /mnt/mine that are no longer there because it isn't. The same problem exists with symbolic links. If you have no symbolic links, do a 'ls -f' in the directory that is giving problems. The entry that is immediately before the one giving you problems is probably the one with the bad .. link.
LOGIN@sobeco.UUCP (LOGIN) (08/06/88)
From article <1235@unisoft.UUCP>, by asa@unisoft.UUCP (Asa Romberger): > In article <3920006@hpirs.HP.COM> banton@hpirs.HP.COM (Butch Anton) writes: >>rich@jolnet.UUCP (Rich Andrews) writes: >> >>> When I am in /usr/lib and execute a find command such as >>> "find . -print" it gets to /usr/lib/uucp and then it fails >>> with a stat() failed /usr/lib/uucp/cd_text. > > I have seen this sort of behaviour also. For me it has always been one simple > thing. It turns out the find does not keep track of full path names of > directories that it is searching. It changes down into a new directory and > then expects to be able to change back to the higher directory by doing a > cd .. Checking source, I find that this is true. > [...various causes deleted] It will also cause problems on NCR TOWER systems using 'rmount'ed directories. Please note that the tower 'rmount' is basically a directory->directory symbolic link; no network stuff is involved. The general rule is: if cd .. won't get you back to EXACTLY where you came from, you have problems with find.