Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!ucsd!ucbvax!ulysses!ulysses.att.com!gsf
From: gsf@ulysses.att.com (Glenn S. Fowler)
Newsgroups: comp.os.misc
Subject: Re: Hard links, necessary evil?
Message-ID: <14810@ulysses.att.com>
Date: 16 May 91 14:48:35 GMT
References: <53680@nigel.ee.udel.edu> <1991May15.165958.22050@kithrup.COM>
Sender: netnews@ulysses.att.com
Organization: AT&T Bell Labs
Lines: 74

In article <1991May15.165958.22050@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <53680@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>> I've been trying to figure out what hard links are good for.  I

> You came up with a short list of useful things, missed all the obvious
> points that links are good for, and think they're *evil*?

first comments on the original posting

>> 1) compress/uncompress/zcat are all one program.  SOLUTION: add a flag, 

many shells have alias/function to handle this

>> 3) Allows same file to appear multiple places in the namespace. SOLUTION:
>>    use full path names for distant files, or use symbolic links or logical
>>    assignments.

a point to note is that each path to the file may represent a different set
of directory access permissions -- however, mounts can also provide multiple
paths to the same file

also, some os's (plan 9) provide unpriveleged process level file name space
binding to achieve the multiple path effects of mount 

>> 4) Allows multiple people to access a file, with the file remaining until
>>    all have deleted it.  SOLUTION: Maybe add a "link-count" without 
>>    actually allowing links.

lose the old paradigm and use semaphores or locks for concurrency

> You came up with a short list of useful things, missed all the obvious
> points that links are good for, and think they're *evil*?

questioning the necessity for hard links is valid and thought provoking
there are modern file system implementations with no hard links -- plan 9
hard links do impose a level of complexity on the os and application programs
they also carry along special case baggage -- directory hard links

> How about this:  "." and ".." (at least until recent versions) were *not*
> special.  The only thing special about them was that mkdir(2,1) would put
> them in there.  Because they were just links to the appropriate places, you
> could either change them around, if you wanted to, or keep them their, or
> even come up with your own scheme (say, "..." is ../..).

. and .. can and have been be special in UNIX, POSIX (yeah, a recent version)
doesn't even require them to be physically present in a directory
also, rmdir(2,1) refuses to remove . and ..

a look at some namei (path name to inode) implementations shows special cases
for . and .. that avoid going to disk for info that is already available

> And, oh yeah:  symlinks take up disk space.  Links only take up space in a
> directory.

directory space is disk space
granted, symlink text usually takes up more bytes than the hard link inode num,
but there is no requirement that symlink text reside in a separate inode
symlinks can be implemented as a directory object with the link text kept
in the directory itself

agreed that dropping hard links may introduce file duplication in some cases
also agreed that a file system without hard links is not unix today

> Why am I not surprised to see such foolishness from you?

this is a non-technical aside
the net has really degraded
respect for human beings on the other side of postings is almost non-existent
I can't imagine people blasting the same remarks face to face

now lets continue with a technical discussion

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com