Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 Apollo 5/13/85; site apollo.uucp
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!cord!hudson!bentley!hoxna!houxm!mhuxt!mhuxr!ulysses!allegra!mit-eddie!think!harvard!bbnccv!bbncca!wanginst!apollo!lwa
From: lwa@apollo.uucp (Larry Allen)
Newsgroups: net.bugs.4bsd
Subject: Re: find(1) and symbolic links
Message-ID: <288f184a.116a@apollo.uucp>
Date: Mon, 26-Aug-85 10:04:43 EDT
Article-I.D.: apollo.288f184a.116a
Posted: Mon Aug 26 10:04:43 1985
Date-Received: Wed, 28-Aug-85 10:17:26 EDT
References: <304@oce-rd1.UUCP>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 16

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.
    2) There are problems with loops in the directory structure.  A symbolic link can point to an
       ancestor of the current directory, potentially resulting in infinite loops.  Again this can be
       solved by keeping track of all directories visited so far, but it would be slow, especially on
       big searches.

As an aside, note that this issue of following symbolic links is a "gotcha" in systems which provide both
System 5 and 4.2Bsd compatibility, like Apollo's.  We have added an lstat(2) call to the System 5 library,
and modified programs like find and du which search the directory tree to use lstat and hence to avoid
following symbolic links.
                                                                    -Larry Allen
                                                                     Apollo Computer