On Friday 12 February 2010 05:41 AM, Patrick O'Callaghan wrote: > On Thu, 2010-02-11 at 23:23 -0800, Suvayu Ali wrote: >> Hi everyone, >> >> When I tried to hardlink a directory today I ran into this, >> >> $ ln muse test >> ln: `muse': hard link not allowed for directory >> >> So I did a little searching and found its not exactly a forbidden. So >> far the closest to an understandable explanation/reasoning I came across >> was a discussion in lwn[1]. So my question is how are hardlinks so >> different from softlinks? > > A hard link is a directory entry that references an inode. Every > property of the file is represented in the inode, including its type, > ownership, permissions, size and pointers to the actual data, i.e. the > directory entry is simply a (name, inode) pair. As such, there can be > multiple directory entries referencing the same inode. > > If the inode type is "directory", reading the data gives us another > level of the file hierarchy. However, consider what would happen if one > of the entries in this second level pointed (directly or indirectly) > back to the parent directory. Very early versions of Unix actually > allowed this, until people realized that you could create a circular > structure that was unreachable from the filesystem root, which would be > a Bad Thing (tm). (Note the analogy to garbage collection problems in > LISP and other languages). > > In order to avoid this, the rule was established that you can't link to > directories, except when the directory itself is being created, at which > time two special entries are placed in it, called ".", and "..". These > are inserted directly by the system itself and are the only exceptions > allowed. This forces the entire structure to be a tree and not an > arbitrary graph. Okay, I now understand the aspect of "." and ".." being the only two hardlinks allowed for directories. However in the lwn discussion I linked to in my OP, one poster mentions the special case of a chroot. Does that mean this is something the kernel(?) decides for us, Or is it this treatment of "." and ".." universal? > However, as the space of inode numbers is local to a specific > filesystem, links cannot cross filesystem boundaries. Thus at a later > stage of development, the BSD version of Unix introduced symbolic links > as a way round this. A soft or symbolic link is just a file that > contains the name of another file (or directory or whatever). It's > marked as a soft link so the system can dereference it when it appears > in a path. Since it's just a name, there are no restrictions on what it > contains, in fact it may not point at anything that actually exists, and > of course can actually create a circular structure. Unix systems prevent > chaos by forbidding infinite deferencing in pathnames, i.e. the system > counts how many components have been traversed while trying to get to > the file, and throws an error when the count exceeds a certain number, > e.g. 17. This is a kludge but it keeps things sane. Note that no file > can exist which *only* has symbolic links to it. Once the last hard link > is broken, the file disappears. Note also that the inode maintains a > count of hard links, but not of symlinks, i.e. symlinks are in some ways > second-class citizens. So essentially since hardlinks deal with inodes directly, the best way to prevent the problem of recursion is to proactively forbid it instead of using external checks like keeping count? > Soft links are similar to "aliases" on Windows. AFAIK Windows has no > concept analogous to hard links. Thank you Patrick for this wonderfully detailed response. It took me quite a while to read, re-read and understand everything you mentioned. Appreciate it :) > > poc > -- Suvayu Open source is the future. It sets us free. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
