🚀 go-pugleaf

In article <398@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:
>In article <8906300342.AA12274@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>>
>>	Soft links are better than hard links period.
>>
>>	* Removing a softlink removes the softlink, NOT the file it is pointing
>>	  to
>And yet there are times when you want to set things up so that removing
>the softlink *does* remove the file itself, if the file (inode) reference
>count goes to zero. This can't happen with soft links, where only one
>of the file references is the real file.

	To totally delete a hardlinked file, you must delete all the links/
files.  To totally delete a soft-linked file, you must delete all the softlinks
and the original file(link).

	Plus I don't see what these times you reference are.

>>	* You can create soft links to non existant (or not yet existant) paths
>
>And yet there are times when you *want* a complaint if the file doesn't
>exist yet, or to be able to preserve a file simply by linking to it.
>With hard links, you can link to someone else's file, and they can delete
>it when they're done with it without worry, because you can do the same
>independently. With soft links you'd have to take the extra steps of
>copying the file somewhere safe, replacing the original sole definition
>of the file with a soft link, and then eventually coordinating with 
>everyone to see when and whether the file body should be deleted. Or in
>practice forgetting about it, everybody deletes their soft links, and
>the file needlessly takes up disk space.

	Getting a complaint on a non-existant destination when linking is easy.
As for your "multi-user" example, this may occur, but not often in my
experience in multi-user and workstation Unixes (in fact, I've never felt
any need for a hardlink, but I've often used softlinks - every day, in fact).

>>	* You can have soft links across filesystems
>
>On Unix, using hard links to files on the same file system
>gives a performance advantage over soft links, since opening the
>hardlink immediately gives the inode reference, whereas soft links
>require a second path search to find the real inode. So far it seems
>to me that the same could be true on AmigaDos.

	Hard links are faster, true, but they're considerably less flexible.
Also, I don't see the speed diferential as being bad (AmigaDos already dos
better than most unixes by having hashed directories, which are fast at
finding a specific entry).

>>	* It doesn't require any hacking on low level FS structures
>
>Implementation detail.

	Yeah, but a real nasty one.

>>	Hard links are dangerous because:
>>
>>	* They are not easily supportable under AmigaDOS due to the filename
>>	  being in the file header (inode) instead of the directory entry
>>	  (what directory entry!).
>
>Implementation problems are a secondary issue after consideration of
>desirability.

	Not when they mean an extra month or two of work for us, plus a slew
of new bugs to weed out (FFS/OFS is getting rather crufty already, in trying
to support things it wasn't designed to, especially since the same handler
must deal with OFS disks, and write OFS disks that can be read by 1.3
machines - no disk format changes).

>The circularites don't come about on Unix because you are prevented
>from hard linking to directories. Multiple backups are prevented on
>AmigaDOS by the archived protection bit.

	And because unix backup programs explicitly ignore softlinks.

>I
>hate to do "cd directory; cd .." and discover that I haven't returned
>to where I started. This never happens with hard links.
>	Doug

	True, but we may not be able to support that under AmigaDos hard links,
even if we do them, simply because the design of the FS doesn't make it easy.

	Plus, I think the shell should remember how you got where you are, 
so cd'ing up one level will make it subtract 1 level from the previous string
for current directory, then CD there.  (cd /foo/bar/zed, where zed is softlinked
to /bar/foo/zed.  The shell would remember /foo/bar/zed as your current dir.
Then you cd .., and it removes zed from /foo/bar/zed, leaving /foo/bar, and
cd's to there.)

	Also, how often do you cd to a hard-link on unix? :-)

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup