| |||||||||||||
Why not just not support hard links?Why not just not support hard links?Posted Sep 2, 2004 19:44 UTC (Thu) by walles (guest, #954)In reply to: Why not just not support hard links? by xtifr Parent article: More notes on reiser4
> when a process opens a file, it actually creates a new hard link, internal
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?
(Log in to post comments)
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 (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.)
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.
|
|||||||||||||