. 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
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds