hard links to directories [LWN.net]

hard links to directories

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

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

(Log in to post comments)

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...