Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!rutgers!bellcore!texbell!uhnix1!moray!splut!sugar!peter
From: peter@sugar.hackercorp.com (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Soft links vs hard links (was Re: yet another 1.4 request)
Message-ID: <3992@sugar.hackercorp.com>
Date: 5 Jul 89 18:10:57 GMT
References: <8906302004.AA16719@postgres.Berkeley.EDU> <1092@sas.UUCP>
Organization: Sugar Land Unix - Houston
Lines: 24

In article <1092@sas.UUCP>, toebes@sas.UUCP (John Toebes) writes:
> With softlinks, the file system needs to be able to communicate with other
> filing systems *ASYNCHRONOUSLY*.

Only if you're requiring that softlinks have full UNIX symbolic link
semantics. I understand that's not considered a requirement in the
first release.

Also, if you implement the links in dos.library the whole problem goes
away. Of course duplicating namei() in dos.library is a bit of a performance
hog... how about this: if a handler sees a soft link it returns a flag
that says "this is a soft link", the contents of the link, and the rest
of the file. dos.library would call DeviceProc on the new link and cons
up the new name, passing it to the new handler. No recursion in the file
systems, at the cost of requiring people to use dos.library to get hold
of files...

do.library is opverdue for a complete rewrite anyway.

And hardlinks are only easier if you don't require full UNIX semantics, which
is a bit unfair.
-- 
Peter "Have you hugged your wolf today" da Silva      `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com  'U`