Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!voder!pyramid!ctnews!mitisft!bob
From: bob@mitisft.Convergent.COM (Bob Lee)
Newsgroups: comp.unix.wizards
Subject: Re: Should find traverse symbolic links?
Message-ID: <1888@mitisft.Convergent.COM>
Date: 28 Feb 91 18:32:43 GMT
References: <1991Feb25.130613.2553@phri.nyu.edu> <15319@smoke.brl.mil> <124226@uunet.UU.NET>
Reply-To: bob@mitisft.UUCP (PUT YOUR NAME HERE)
Organization: Unisys Network Computing Group, San Jose
Lines: 28


The problem comes in the basic concept of the Unix file system.
That file system pre-supposes a straight b-tree; however, when you
add unrestricted directory level links or multiple mount points that
assumption is no longer true.  The abstract then becomes a network
and not a b-tree (the b-tree being a degenerate case of the network).
In that environment recursive operation must take great care with
any link or mount point that has the potential to create a loop in
the "tree".  The exclusion of symbolic links and mount points should
be the default action in my opinion, but the means should be there
to include these in say a "find" or "ls" operation.

I worked on a system that allowed multiple mount points etc., and it
can be managed.  However, the user must be aware of this subtle difference
or be guarded by the default but not excluded from making use of it.
I would maintain that the moment you include any primitive that allows
the creation of a loop in the file system you no longer have a real
traditional Unix file system and as such traditional methods will break
down at some point.  The solution, I believe, is education (change the
way we tell people about the file system, no more pure b-tree drawings),
documentation (call a spade a spade, it will no longer be a b-tree but
a super-set), and protection (proper choice of defaults in utilities
the recursively desend (or should the term now be navigate) the file
system).

-bob

all the standard disclaimers apply, and sorry if I rambled a bit