Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Why not just not support hard links?Why not just not support hard links?Posted Sep 2, 2004 19:24 UTC (Thu) by xtifr (subscriber, #143)In reply to: Why not just not support hard links? by walles Parent article: More notes on reiser4
A hard link is basically just something (usually a name) that points directly to an inode, rather than linking indirectly to another name. So pretty much every file on your system (except for the symlinks) is a hard link. (Actually, even symlinks are usually hard links to inodes containing the symbolic reference, so every symlink is a hardlink - but I believe there are filesystems where symbolic references can be stored in the directory structure, so this is not a hard-and-fast rule. But it is a common one.)
If you mean that you never use more than one hard link per inode (not counting the automatic "." and ".." hardlinks that all directories have), well, even that's pretty tricky - when a process opens a file, it actually creates a new hard link, internal to the process (not associated with any name on the filesystem). So, if you forbid multiple hard links, you lose the ability to open files (unless you delete them as you open them), which would make the files a bit useless. :)
Also, as others have mentioned, hard links are slightly smaller and faster than symlinks. This may not matter to you but it does matter to some people, especially people working with small embedded systems, and the insane performance fanatics who take a wasted CPU cycle as a personal affront (I'll try not to mention any Gentoo fans by name here.:)
Using symlinks also requires you to have a primary, privileged name (the main hard link). Sometimes this isn't convenient. For example, I'm not entirely sure how I want to organize my music: by artist or by genre. Currently I have two directory trees populated with hard links to the same music files. If I used symlinks, one of those trees would have to be privileged, and would be very hard to get rid of if I decided I didn't need it any more.
(Log in to post comments)
Why not just not support hard links? Posted Sep 2, 2004 19:44 UTC (Thu) by walles (subscriber, #954) [Link] > when a process opens a file, it actually creates a new hard link, internal> to the process (not associated with any name on the filesystem)
I'm not sure I'm following this. The article text says that hard links to directories are forbidden, but libc still has an opendir() call. If what you say above is correct, how come opendir() doesn't have to delete directories upon opening them?
> Using symlinks also requires you to have a primary, privileged name
What do you mean with "privileged" name? And why would such files be hard to get rid of?
Why not just not support hard links? 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.
Why not just not support hard links? Posted Sep 3, 2004 16:46 UTC (Fri) by hppnq (subscriber, #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.)
Why not just not support 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 thefilesystem (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.
|
|||||||||||