Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gatech.CSNET
Path: utzoo!linus!gatech!arnold
From: arnold@gatech.CSNET (Arnold Robbins)
Newsgroups: net.bugs.4bsd
Subject: Re: using utimes(2) to change the time of a link
Message-ID: <705@gatech.CSNET>
Date: Wed, 31-Jul-85 13:23:41 EDT
Article-I.D.: gatech.705
Posted: Wed Jul 31 13:23:41 1985
Date-Received: Thu, 1-Aug-85 20:37:23 EDT
References: <4809@mit-eddie.UUCP> <266@brl-tgr.ARPA>
Distribution: net.bugs.4bsd
Organization: Pr1mebusters!
Lines: 31
Summary: a reason why to monkey with symbolic links

In article <266@brl-tgr.ARPA>, gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
> Why are there so many inquiries about doing things to the symbolic
> links instead of to the files to which they point?  It doesn't seem
> to be necessary..

It sure is necessary if you're writing/using a file system backup program.
I've been converting a really nice program from System V to 4.2 BSD, and
symbolic links have been the hardest part.  As it currently stands, when
restoring a symbolic link, you can't restore the mod time on the link itself,
or change the mode. (In fact, I have to now add code to check for that!)

I hope 4.3 cleans up some of their semantics.  For instance, the following
code creates a symlink that 'ls' says is l--------- (mode 000):

	...
	umask (0777);
	symlink ("old", "new");
	...

'new' is mode 000, but a readlink(new,...) will succeed!  I'm not sure exactly
what should happen, but I don't think the readlink should succeed.

In sum, I think symbolic links are nifty things, but there are some things
about them that could use redefining (or at least clarifying).
-- 
Arnold Robbins
CSNET:	arnold@gatech	ARPA:	arnold%gatech.csnet@csnet-relay.arpa
UUCP:	{ akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

Hello. You have reached the Coalition to Eliminate Answering Machines.
Unfortunately, no one can come to the phone right now....