Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 (Fortune 01.1b1); site graffiti.UUCP
Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!ut-ngp!shell!graffiti!peter
From: peter@graffiti.UUCP (Peter da Silva)
Newsgroups: net.bugs.4bsd
Subject: Re: find(1) and symbolic links
Message-ID: <146@graffiti.UUCP>
Date: Sat, 31-Aug-85 10:10:02 EDT
Article-I.D.: graffiti.146
Posted: Sat Aug 31 10:10:02 1985
Date-Received: Mon, 2-Sep-85 09:32:44 EDT
References: <304@oce-rd1.UUCP> <288f184a.116a@apollo.uucp>
Organization: The Power Elite, Houston, TX
Lines: 13

> In all of the 4.2bsd implementations I know about (VAX, Sun, Apollo), find(1) is specifically arranged
> to not follow symbolic links.  There are a couple of reasons for this:
>     1) If you follow a symbolic link, it's hard to get back.  Going back to .. doesn't work; instead,
>        find would have to explicitly keep a stack of the directories it had visited.  While this would
>        work, it would require find to do a getwd(2) at every directory level, and getwd is pretty slow.

Why would it require find to do a getwd? The file spelling checker in Kernighan
and Pike doesn't. All you have to do is build the directory stack on the fly.
I always assumed find did this rather than depending on ..

hyd-ptd!/usr/src/news and hyd-ptd!/usr/spool/uucp/news.src were the same file
for a while when I was trying to get uucp up on datafact. Find never got lost
here, that I recall.