hard links to directories [LWN.net]

hard links to directories

Posted Sep 14, 2007 3:13 UTC (Fri) by Duncan (guest, #6647)
In reply to: hard links to directories by gw666
Parent article: The many faces of fsck

> So if a directory has a link count > 1, this must be an error.

What are all the (normally hidden) . (me) and .. (my parent) links if not
hard links?

Your assumption that additional links are not allowed doesn't necessarily
hold for all filesystem types, either. Looking it up, the GNU coreutils
info entry for ln has the following:

> On all existing implementations, you cannot
> make a hard link to a directory, and hard links
> cannot cross file system boundaries. (These
> restrictions are not mandated by POSIX, however.)

Thus multiple named directory links are apparently not only possible, but
not restricted by POSIX either, so an implementing filesystem could indeed
allow such things, it's simply that few (none known to the info entry
author quoted above at the time the statement was written) have done so.

Hmm... That leads to two questions.

1) What does creating a subdir do if it doesn't create a hardlink entry in
the form of .. back to the parent? Does the above only refer to directly
created named (not . and ..) links?

2) The no crossing filesystem boundaries is interesting. The kernel must
fix that up by creating a logical .. link in the root dir of a mounted
filesystem, since it self-evidently couldn't be a hard-link, given that
the filesystem could be arbitrarily mounted anywhere. Likewise, the
kernel must remove the .. entries from chroots.

So maybe those . and .. entries aren't hard links after all, which begs
the question (avoids the question, begs that it be asked and answered,
whatever [1], I'm a literal constructionist in this case) I asked at the
beginning, what /are/ they, then? However, that's out of my league.
Perhaps Val can trivially answer.

[1] http://www.onelook.com/?w=beg+the+question

Duncan

(Log in to post comments)

hard links to directories

Posted Sep 14, 2007 6:32 UTC (Fri) by nix (subscriber, #2304) [Link]

The . and .. directory entries in the roots of filesystems don't actually
exist, but are faked by the VFS. (There's no reason why the filesystem
couldn't generate all . and .. entries that way, and IIRC some do.)

Once upon a time . and .. really were real hardlinks,
and /usr/lib/{mk,rm}dir (IIRC) were setuid root programs that
created/removed the directory and manipulated these links. This turned out
to have unfixable races, so was replaced with an in-kernel call, but some
Unixes (notably Solaris) maintained the semantics that unlink() of a
directory as root was permitted (which caused some aggro on the git list
recently).

Multiple hardlinks to a directory are theoretically implementable, and
under Linux the biggest problem (`where does .. take us?') is solvable
using the dcache; but allowing it will confuse users to some extent.

(Linus said that he had no major objections to allowing directory
hardlinking --- the we don't corrupt filesystems kind --- about seven
years or so ago, but nothing happened after that that I know of.)

hard links to directories

Posted Sep 14, 2007 11:07 UTC (Fri) by Duncan (guest, #6647) [Link]

Thanks. Useful information. I hadn't thought out the implications of ..
to multiple named hard-linked dirs myself, so I'm glad you pointed it out.
It also explains the notes on directory unlink that I'd read (the
root-only thing, and that the exception was directory specific) but never
really understood. I understood that the subject went deeper than I
understood; now I'm beginning to see just a few of the ways it does so.

But just to be sure, now, . and .. are indeed hard links within a
filesystem, on at many (but not necessarily all) filesystem
implementations? You specified that the entries in filesystem roots are
faked (as I was beginning to realize), but left not quite as nailed down
as I'd like that they are indeed hard links within the filesystem, even if
they are exception links that require kernel calls to create/destroy.

Anyway, the kernel calls thing explains somewhat why filesystems haven't
implemented this yet. That's an additional complication, and would
certainly be heavily scrutinized if anyone tried introducing a filesystem
of that nature into the kernel mainline... which pretty neatly ties into
exactly why reiser4 has had the problems it has had getting into mainline,
given the original file as directory idea and implementation thereof. Now
I understand the implications of /that/ debate a bit better too, and a bit
more about what the nature of the introduced races and the complaints
about them entailed.

Duncan

hard links to directories

Posted Sep 14, 2007 19:34 UTC (Fri) by nix (subscriber, #2304) [Link]

. and .. appear as hard links to users of the VFS. That doesn't mean they
have any physical existence, especially not at filesystem roots.

The VFS and layers below manage . and .. entirely on their own: users just
call mkdir(2), rmdir(2), or rename(2) on the directory and the kernel does
all the rest.

The file-as-directory idea, while beguiling (especially for structured
file formats) has *many* more problems, not least that whether specific
programs were willing to treat a file as a directory or vice versa, or
both, would depend on currently-irrelevant details of how they were coded.
It is currently safe for a program to stat() something and then switch on
its d_type; but what d_type does a file-and-directory return? If it's new,
nothing much will support it unless you hack the S_ISREG() and S_ISDIR()
macros to return true for the new type too (and that's an ABI change: new
glibc major version!): if it's nailed to S_IFREG, very little will treat
it as a directory, and vice versa if it's nailed to S_IFDIR.

I wish it could be implemented, but unless we're willing to throw away our
existing software, I suspect we'll be stuck with kludges that expose both
as different faked-up-but-aliased inodes somehow, one a file, the other a
directory.

hard links to directories

Posted Sep 15, 2007 14:59 UTC (Sat) by sflintham (subscriber, #47422) [Link]

For what it's worth, and assuming I haven't misunderstood, Acorn's RISC OS had/has the concept of thing-which-is-a-file-and-directory. There were programs that made things like zip files behave as if they were a directory, and IIRC when another program asked the OS 'is this a file or a directory', it returned a bitmap where (say) bit 1 signalled 'this is a file' and 2 'this is a directory', and both would be set. Naturally this slightly broke programs that were written before they added this feature which just checked for a 1 or 2 value, but I don't remember it causing too many problems.

Not trying to argue a case for or against making the change in Linux here, just thought I'd drop this in...