Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!unisoft!asa
From: asa@unisoft.UUCP (Asa Romberger)
Newsgroups: comp.bugs.sys5
Subject: Re: find fails
Message-ID: <1235@unisoft.UUCP>
Date: 3 Aug 88 15:47:40 GMT
References: <673@jolnet.UUCP> <3920006@hpirs.HP.COM>
Reply-To: asa@noir.UUCP (Asa Romberger)
Organization: UniSoft Corporation, Emeryville Ca.
Lines: 33

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.