Why not just not support hard links?

Posted Sep 2, 2004 13:23 UTC (Thu) by utoddl (subscriber, #1232) [Link]

I have a script that makes good use of hard links -- not for space saving so much as time saving, but it saves a lot of space as well. I keep a copy of my RedHat/Fedora/whatever ISO images, and occasionally use wget to grab all the updates into another directory. These updates contain all 19 gazillion versions of the updated packages -- way more than will fit on a CD -- when what I really want of course is the latest version of each. So I use cpio to make a hard link duplicate tree of all those updates (i.e. real directories, hard linked files). That's pretty quick, 'cause it's not moving any data, just creating dir entries. Then my script throws out everything I don't want from that tree -- all the older versions of a given rpm -- and I'm left with a small enough set of rpms to fit onto a CD. I add my own favorite goodies that aren't on the distro (config files, utilities, etc.), and burn an ISO from that. That gives me the original distro CDs plus an extra CD with all current updates and my favorites all on CDs I can carry around so I can install on and update the various boxes I play with at home, work, friends' and family's houses, wherever. (Heck, I'll stick a copy of the scripts here if anybody wants to play with 'em.)

Using hardlinks for this was a natural. Having said that, I recall only using hardlinks once before, a long time ago, and that was specifically for space savings.

Posted Sep 10, 2004 0:46 UTC (Fri) by roelofs (guest, #2599) [Link]

So do you (or anybody else for that part) know of any other uses for hard symlinks that don't have anything to do with space savings?

Assuming you really meant "hard links," I use them to avoid accidentally deleting local mail files. Since such files get updated every day, usually several times a day, even daily incremental backups aren't sufficient to recover from an accidental deletion. But with hard-linked copies in a separate directory (e.g., ../.backups/foo.backup, etc.), you're safe. (And when you really do want to nuke the file, just truncate it to zero bytes--I wrote a trivial "trunc" utility that simply uses truncate() or ftruncate() for this purpose.) Of course, I suppose I could simply keep the "real" copy in the same hidden directory and use local symlinks to append to it...but with hard links you save one letter in every ls(1) command (i.e., -L). :-)

I've also occasionally used hard links to save a temporary MPEG or PDF file downloaded by Netscape; under some conditions, the temporary file will disappear as soon as the download is complete, but if you make a hard link at any point prior to that, the link will remain. For multi-megabyte downloads, that can be convenient, albeit not absolutely critical...

Greg

Posted Sep 2, 2004 11:26 UTC (Thu) by hensema (guest, #980) [Link]

You cannot symlink to files outsides a chroot. So, if you want to create a chroot jail without hard links, then you'd have to copy all files you need inside the chroot, effectively duplicating those files.

However, with hard links, you only need one instance of a file on disk, which saves space.

Note that hard linking from inside a chroot to main system files (such as /bin/bash) is not a very smart thing to do, as chrooted users can then modify exactly the files you wanted to prevent them from modifying. So you always need two copies of a file.

Posted Sep 3, 2004 16:41 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

He's using a rather expansive definition of "hard link." Usually, "hard link" refers only to a reference to a file from a directory entry. The kind of reference you get when you open a file isn't called a hard link. (It's just called a reference).

Incidentally, most of this thread is using "hard link" in a too restrictive way. When you create a file 'foo', you create one hard link to the file (from the directory entry with name 'foo'). When you ln foo bar, you create a second hard link to the file. Note that Unix files themselves do not have names -- not text ones anyway; they are traditionally named by inode number.

Directories have lots of hard links. There's the one from the parent directory, the one from '.', and all the ones from the subdirectories' '..' entries. In some modern models, '.' and '..' aren't actually considered directory entries, but you'll still see them -- for historical purposes -- in the directory's link count (e.g. from ls -l).

But you can't make an arbitrary hard link to a directory. Only the specific ones described above are allowed to exist.

Posted Sep 3, 2004 16:46 UTC (Fri) by hppnq (guest, #14462) [Link]

What do you mean with "privileged" name? And why would such files be hard to get rid of?

I suppose what is meant is, that with symbolic links there is a distinction between the actual file and the link: removing the symbolic link leaves the file intact, while removing the file leaves you with a link pointing nowhere. This, of course, is because there are two separate inodes (the entities that keep the metadata): a symbolic link has its own inode. With hard links, you merely remove one of the references to the file (this is a number in the inode that is increased whenever a hard link is created), leaving it intact until the last link is removed. In this respect, all link names are "equal" then.

Getting back to your original question: this is also one of the reasons why you would want to use hard links. (In practice, symbolic links are almost always preferable. You should really know what you're doing when using hard links.)

Posted Sep 4, 2004 21:38 UTC (Sat) by Ross (subscriber, #4065) [Link]

Because another process can't use that opened directory to traverse the
filesystem (even /proc/self/cwd is just a symlink). The same thing with
open files. They prevent the item from being removed from the disk, but
they don't mess with the namespace.