Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!husc6!panda!genrad!decvax!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix
Subject: Re: Are links as useful as they could be?
Message-ID: <7966@sun.uucp>
Date: Tue, 7-Oct-86 04:14:50 EDT
Article-I.D.: sun.7966
Posted: Tue Oct  7 04:14:50 1986
Date-Received: Wed, 8-Oct-86 07:12:40 EDT
References: <21127@rochester.ARPA> <65@its63b.ed.ac.uk>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 34

> The "check for looping" could be fixed for symbolic links by defining
> some primitive that converts a filename into the filename that it
> "really is" -- ie, it does the work that it does internally in order
> to do things like open(), execle(), etc... on a symbolic link.

Huh?  The "check for looping" is there to prevent calls like "open" from
looping:

	ln -s a b
	ln -s b a
	cat a

I presume the primitive you're referring to would be something like:

	int evaluatelink(const char *path, char *buf, int buflen);

which would take the path pointed to by "path" and return the path name of
the file it ultimately refers to in the buffer whose first character is
pointed to by "buf", transferring at most "buflen" characters.

How would this help?  If that primitive does the work that the kernel does
internally for things like "open", it would have the same problems as those
calls, and would have to do the same check for looping.

> lstat() is fine but it only does one level of translation.

Huh?  "lstat" does *no* translation; that's what it's there for.  It finds
the file referred to by the path argument, assuming *no* symbolic-link
translation, and returns its file status.  "stat" does symbolic-link
translation.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)