On Fri, 2008-04-11 at 11:30 -0500, Bruce Dubbs wrote: > Randy McMurchy wrote: > > Christian Wurst wrote these words on 04/11/08 06:50 CST: > > > >> I'd say making the book more consistent (in itself, but also with LFS) > >> is a reason too. If we do symlinks here (vim for instance) and > >> hardlinks there (ed), without a clear reason why, it might confuse > >> readers. If we differ from a standard way of doing things there should > >> be a reason - and it should be explained in the book why it is done > >> different in this case. > >> If my explanation about the differences of hard and symlinks is > >> correct, I can really live with both. But we really should have a > >> standard way to do it. > > > > Thanks for the input Christian! I'm also hoping Ag will comment, > > especially about "unnecessary" hard links. > > > > As far as your comment about "standard way to do it", I want the > > standard way to be: leave it as the package author wrote it, unless > > there is a problem with how he did it, or we can make it significantly > > better by changing it. > > > > Changing a hard link to a soft link doesn't fit in either of those > > categories. > > I agree with Randy's policy. > > A couple of notes about hard vs soft (symbolic) links. All hard links must > be > on the same file system. This is not true of soft links. Hard links means > that > there can never be a "dead" or non-existing link target. > > Second, you can not have a hard link to a directory. It has the potential to > create loops in the file system that would cause havoc. Of course, you can > have > a soft link to a directory. > > Third, symbolic links take up slightly more disk space than a hard link. A > hard > link is only an inode. The soft link uses an inode and an additional block > with > the path to the target files. > > Fourth, directories contain hard links to each file contained in that > directory. > > Fifth, hard links can have different permissions and ownership. That does > not > really make sense for symbolic links, even though it is possible. > > -- Bruce
If I may offer my 2 pesos on this Hard Link When multiple file names in the file system refer to a single inode , the files are called hard links to one other. All file names must reside in the same physical file system. When a file has multiple hard links, each of those file names is an exact peer, and there is no way to tell which file name was originally used. Removing one hard link does not remove the file from the device, it stays until all the links to it are removed. Symbolic Link Are more flexible than hard links, but don't share the peer relationships. Hard links share an inode, symlinks point to other file names. If the destination file is removed the result is a dangling link. Can be use between sub directories and cross physical file system boundaries. It still may be true (I have not checked) that chown() lstat() readlink() rename() and unlink() system calls (I am talking C here) do not follow symbolic links. FWIW is think leaving the hard/sym link is best kept like the author of the package. -- Tayo'y Mga Pinoy -- http://linuxfromscratch.org/mailman/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
