Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <18529@louie.udel.EDU>
Date: 26 Jun 89 21:09:55 GMT
References: <0933.AA0933@caleb> <1989Jun16.151408.8382@ziebmef.uucp> <3940@sugar.hackercorp.com>
Sender: usenet@udel.EDU
Reply-To: new@udel.EDU (Darren New)
Organization: University of Delaware
Lines: 36

In article <3940@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>In article <1989Jun16.151408.8382@ziebmef.uucp>, mcp@ziebmef.uucp (Marc Plumb) writes:
>> In article <0933.AA0933@caleb> jdp@caleb.UUCP (Jim Pritchett) writes:
>> >This is yet another 1.4 request.  Could file links be added?  How difficult
>Hard links wouldn't be worth it, given the way Examine and ExNext work. Soft
>links would be easy... you would just store the new file name in the comment
>feild.

Even better, leave the comment field alone and store the new name in the
list of blocks the file uses. But since we probably want to not make the
name so short, we (royal we) would use both the block list and the comment
field and the date and the protection bits, possibly overflowing into 
actual data blocks. As hard disks and networks get larger, restricting 
file names to 80 characters could be a problem. Now what happens if 
ExNext runs across a soft link to something on a non-mounted volume?
Do we prompt the user to put in that volume, or what? Say it is on
the same volume: how does ExNext tell the user it is a soft link
without breaking existing software? I would suspect that most
directory scanners either say
  IF directory-block THEN xxx ELSE yyy;
		 or
  IF regular-file THEN yyy ELSE xxx;
Adding a new case could cause lots of problems. Of course, we could
always change ExNext to look for the linked-to file and make NewExNext
return more status information. But then what happens when the soft-link
and the linked-to file are in the same directory? We wind up seeing and
maybe trying to delete the same file twice? Should a Lock on a soft-link
file actually lock the linked-to file also? If not, won't opennng the
file twice cause problems? If so, what if we really want to lock
the soft-link?
I think this is not quite so easy as it seems. (It never is, is it? :-)
		-- Darren (good at finding problems,
			   lousy at fixing them) New


a problem.