jrg@Apple.COM (John R. Galloway Jr.) (07/18/90)
[ Moderators Note:- Here's one good reason - speed! It is a lot faster to follow a hard link than a symbolic link. - Der ] I am interested to know what uses people routinely have for hard links that could not be equally well served by symbolic links. Obviously the difference is that if the target of the link moves or is deleted, the hard link still works while the symbolic link does not. I am NOT interested in hearing if theoretically this is a problem (this includes internal issues like . and ..) but, in your real daily use (not imagined or possible use), would only having symbolic links be a problem? For me, it would not (unless there are some hidden on my system I don't know about :-) The issue is that reference counts are a pain for a new file system I am working on and I would like to get rid of them and it seems like hard links are difficult without them (or some global garbage collection scheme which I don't want either). Please respond to jrg@galloway.sj.ca.us and I will post the results, and please note further that this has nothing to do with apple (I just haven't got the news feed on galloway set up yet). Thanks! -jrg -- internet jrg@apple.com John R. Galloway, Jr. (soon to be) jrg@galloway.sj.ca.us applelink d3413 CEO..receptionist 795 Beaver Creek Way human (408) 259-2490 Galloway Research San Jose, CA 95133 These are my views, NOT Apple's, I am a GUEST here, not an employee!!
davecb@nexus.YorkU.CA (David Collier-Brown) (10/10/90)
jrg@Apple.COM (John R. Galloway Jr.) asks if one needs hard links in a new file system... >[ Moderators Note:- > Here's one good reason - speed! It is a lot faster to follow a hard > link than a symbolic link. - Der ] Well, if one only requires the symbolic link to point to objects in a file system, one can drop the symbolism and implement a "soft" link with the triple { filesystem type, [unique identifier | mount point], file reference } Chose the second term according to taste: unique identifier costs you a mount-time mapping and allows references to unmounted filesystems, mount point costs you space to represent it (another triple?) and a lookup iff dismounted. Mount points save a lookup at runtime. Of course, one can use a uid when dismounted and a pointer if mounted and try to pull them from the same address space (:-)). --dave [ps: I once wrote code that depended on writing ascii text into Berzerkly symlinks. Text like "file 881543 on tape NX2307".] -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | "And the next 8 man-months came up like CANADA. 416-223-8968 | thunder across the bay" --david kipling
jmm@eci386.UUCP (John Macdonald) (10/10/90)
In article <3718@zorba.Tynan.COM> jrg@Apple.COM (John R. Galloway Jr.) writes: |I am interested to know what uses people routinely have for hard links that |could not be equally well served by symbolic links. In a system administration reporting package we sell, we regularily use hard links to link todays report to "Rpt.<day>" where <day> is the day of the week. Thus we end up with rpt.last being the most recent report generated, and Rpt.Wed being the report most recently generated on a Wednesday. This gives an automatic cyclic backup scheme. The <day> extension is generated by using date, and is controlled by an locally configurable environment variable which allows the numerical day of the month to be used instead to provide a 28 to 31 day cycle rather than a seven day cycle. It would be possible to do the same with a loop that moved all historical items to the next older name, however, it is a lot easier to figure out which is the backup from last Saturday (is it rpt---- or rpt-----?) using our method. -- Algol 60 was an improvment on most | John Macdonald of its successors - C.A.R. Hoare | jmm@eci386