🚀 go-pugleaf

In article <18191@usc.edu> papa@pollux.usc.edu (Marco Papa) writes:
>After the recent flurry of messages about "hardlinks vs. softlinks" let me 
>give my 5 cents:
>
>* If CBM has to chose between including hardlinks and softlinks for 1.4, it
>  is clear that softlinks should be chosen: they are CLEARLY easier to 
>  implement, and seem to be enough for 99% of the cases.
>-- Marco Papa 'Doc'

I hate to pop your bubble on this, but from the standpoint of writing an
AmigaDos filing system (and experience to back it :-) softlinks are 
*SIGNIFICANTLY* more difficult to implement than hardlinks.  With 
softlinks, the file system needs to be able to communicate with other
filing systems *ASYNCHRONOUSLY*.  This is an important point because
of the problem where a file may be linked to another device which in 
turn is a link back to a different place on the original device.  We
haven't even started to scratch the surface of handling details such
as links from filesystems to handlers which support a subset of packet
types or even worse handling any newly defined packets.

Look at how long it took Bill Hawes to get Pathman correct - there are
many loopholes to be handled and some subtle interactions.

Hardlinks on the otherhand, while certainly less flexible, do not require
any external access by a handler.  Yes, there are conceptual problems to
deal with in terms of Examine() and recovering space when deleting entries
not to mention deleting the base object without deleting all links.
Un*x solves this problem by making all file entries links to the inode
that describes the object and keeping a reference count in the inode.
Certainly there are ways that we can make this work but it is not trivial.

At a minimum we are talking a solid month of work including testing of
all the obscure situations (like deleting the linked object in the middle
of two ExNext() sequences) to put in hard links.  To implement softlinks
I would put that estimate between 2 and 3 months because of all the
interactions of handlers and the potential for reving other handlers.

One alternative that might be faster to implement (which may be what you
are thinking about when you described it as easier) would be to implement
soft links which do NOT work across volumes.  This solves reference counts
and the obscure situations.  However, I suspect that this would draw flames
from people who feel that this is a poor job because it is "CLEARLY easy
to implement it correctly to work across devices".  If I had my vote (which
I don't) in this issue, I would opt for implementing ... NOTHING ...
I don't think that the feature is worth the effort that could be better
spent on other parts of AmigaDos to get 1.4 out sooner.

But then again, the above is only my opinion.  You are welcome to implement
a file system and compare experiences.  I know there is some experience out
there now.

--
 |0|\   John A. Toebes, VIII                    usenet:..mcnc!rti!sas!toebes
 |.|/  Coordinator of The Software Distillery   BBS: (919)-471-6436
 ===    Bix: JTOEBES      Plink: JTOEBES     CI$:"sorry Charlie"