🚀 go-pugleaf

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."

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
------------------------------------------------------------------

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

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.   

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.