Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!rti!sas!toebes From: toebes@sas.UUCP (John Toebes) Newsgroups: comp.sys.amiga.tech Subject: Re: Soft links vs hard links (was Re: yet another 1.4 request) Message-ID: <1092@sas.UUCP> Date: 5 Jul 89 12:51:19 GMT References: <8906302004.AA16719@postgres.Berkeley.EDU> <18191@usc.edu> Reply-To: toebes@sas.UUCP (John Toebes) Organization: SAS Institute Inc, Cary NC Lines: 55 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"