Note that the Linux VFS layer was pretty much _designed_ with something
like this in mind. From very early on, I decided that the VFS layer
should not make too much of a distinction between a directory and a
regular file: both have "lookup" properties, and both have "read"
properties.
Some of that has been corrupted over time, and some of it was never done
because nobody actually used it - so there's a few places where the VFS
layer does things like "if (!S_ISDIR(d_inode->i_imode))" etc and thus
"knows" about the difference between a directory and a regular file, but
that was never really meant to be a design goal, and I'd be happy to try
to clean it up.
So basically it all should be doable today: if a low-level filesystem
wants to export directories both as regular files and as pathname
components, it can be done. The low-level FS can look at the
O_DIRECTORY flag to know whether somebody wants to read the thing as a
directory or not (ie "readdir()" obviously opens the directory, while
normal operations open the default file), and it should all work pretty
much today.
It's going to confuse a lot of UNIX applications, but at the same time a
reasonable number of them won't ever really have to know.
>Next files need to be able to inherit stat data, so that a file can
>share its modification time with its parent directory, so that modifying
>the file changes the mod time on the directory.
I don't think that is true. I think the directory and the file should be
considered separate, it's just that "lookup()" can find one or the other
depending on use..
So I think it should be considered a _naming_ issue, and not much else.
>Finally, you need a new file type flag indicating that it is both a file
>and a directory.
Not necessarily. Just open it with O_DIRECTORY (or with a slash at the
end) and it gets opened as a directory, otherwise it gets opened as the
file. Works today, and is the most transparent option anyway.
Things like "tar" etc probably need to be taught about how to see
distinctions like that, and we may want to have other ways of accessing
the information, but I don't think we _have_ to have them.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/