new@ee.udel.edu (Darren New) (05/15/91)
I've been trying to figure out what hard links are good for. I've been able to come up with a few uses as used under UNIX, but I don't think it's worth the hassle of handling hard links in tar, fsck, etc given the benefits. What I'm looking for is feedback on whether or not, were *you* to write a new OS, you would include hard links and why. The benefits of hard links that I perceive (and have been locally pointed out) are these: 1) compress/uncompress/zcat are all one program. SOLUTION: add a flag, possibly allowing the shell to translate "uncompress" into "compress -d" if desired. This info could be stored in a way as to make it easy to access, or as symbolic links. 2) . and .. become simple to implement once hard links are available. SOLUTION: handle . and .. lexically (i.e., in the file name parser rather than in the file system, much as ~user/.... is/should be handled). Most programs which deal with directories already do this: tar and ls don't follow .. for example. 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. 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. 5) The semantics of "mv" become obvious and failsafe. SOLUTION: make "rename" a primitive OS operation. My main objection to hard links is the complexity of managing several names for the same information. For example, tar must keep track of which i-nodes it has seen so as to save only one copy of a multiply-linked file. Hence, I don't object to symbolic links, reference counts on files, and so on. Just wondering about other's thoughts on the subject... -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+ Nails work better than screws, when both are driven with hammers +=+
sef@kithrup.COM (Sean Eric Fagan) (05/15/91)
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*? 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, oh yeah: symlinks take up disk space. Links only take up space in a directory. Why am I not surprised to see such foolishness from you? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
gsf@ulysses.att.com (Glenn S. Fowler) (05/16/91)
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