Path: utzoo!lsuc!attcan!sobeco!LOGIN
From: LOGIN@sobeco.UUCP (LOGIN)
Newsgroups: comp.bugs.sys5
Subject: Re: find fails
Message-ID: <321@sobeco.UUCP>
Date: 6 Aug 88 09:58:38 GMT
References: <1235@unisoft.UUCP>
Organization: Groupe SOBECO (Montreal Canada)
Lines: 26

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.