🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #300

Re: yet another 1.4 request

#300
From: Peter da Silva
Date: Sun, 02 Jul 1989 02:13
69 lines
3252 bytes
I said, speaking of UNIX links:
> :Hard links are "better" than soft links because you can't delete the
> :linked-to file accidentally and suddenly have a bunch of non-existent
> :files around to confuse the hell out of utility programs.

Matt Dillon thought I was speaking of Amiga links. I will agree that in
no circumstances should hard links be implemented on an Amiga file system.
They just won't work. But just in case people get confused...

In article <8906300342.AA12274@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:

> 	Soft links are better than hard links period.

Sorry, I can't agree. The main difference is that hard links are all peers.
This has advantages and disadvantages, true, but...

> 	* Removing a softlink removes the softlink, NOT the file it is pointing
> 	  to

Removing a hard link removes the link, not the file it is pointing to. When
you remove the last hard link the file is reclaimed. This is useful when you
need to give a file a number of names, with no name having priority.

This is an advantage of hard links... removing the "original" doesn't leav
the other links in the lurch.

> 	* You can create soft links to non existant (or not yet existant) paths

Yes. This is an advantage of symbolic links.

> 	* You can have soft links across filesystems

Yes. This is an advantage of symbolic links.

> 	* You can have soft links to devices

You can have hard links to devices, too.

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

Popping back one level, symbolic links require some FS hacking. You need to
stick the name somewhere. I guess you could put it *in* the file...

> 	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!).

Hard links with UNIX semantics aren't supportable at all.

> 	* backup programs would have to deal with circularities and, even when
> 	  found, since there is no distinction between a master or slave link
> 	  the user can get very very confused.  At least with soft links you
> 	  know where you stand.

How do backup programs deal with soft links? You could set up a bunch of files
that seem to have more data in them than the whole disk can hold. A backup
program would have to know about links in either case.

> 	* Hardlinks look like normal files or directories... all the more
> 	  confusing.

In any way that a link *doesn't* look like a normal file or directory it's
a disadvantage. I would hope that, unless you do something special, soft links
also look like normal files and directories.
-- 
Peter "Have you hugged your wolf today" da Silva      `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com  'U`
Technical Details
Message-ID: <3971@sugar.hackercorp.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!nuchat!sugar!peter
References: <8906300342.AA12274@postgres.Berkeley.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!nuchat!sugar!peter
From: peter@sugar.hackercorp.com (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: yet another 1.4 request
Message-ID: <3971@sugar.hackercorp.com>
Date: 2 Jul 89 02:13:06 GMT
References: <8906300342.AA12274@postgres.Berkeley.EDU>
Organization: Sugar Land Unix - Houston
Lines: 69