On Sat, 12 Aug 2000, Alexander Viro wrote:
>
> On 12 Aug 2000, Linus Torvalds wrote:
> >
> > and I'm also claiming that the Linux VFS layer actually shouldn't have
> > any fundamental problems with something like this.
>
> Shouldn't or doesn't? I can tell you what the current problems
> _are_.
I know there are some problems with it right now, but they should not be
design issues.
Right now the VFS layer checks for S_ISDIR() in a few places, in order to
do the O_DIRECTORY tests etc. That will need changes - but those changes
would be required anyway (ie due to the addition of S_IFCOMPLEX mode bit
in i_mode) for handling of these kinds of files.
> a) in a _lot_ of places we are required to distinguish between
> directories and non-directories and yes, a lot of things in userland
> depend on that.
Right. This is the one that actually needs interface changes: something
like
#define S_IFCOMPLEX 0x10000
in <linux/stat.h>, plus changing of tests. And teaching things like "cp"
about it.
> b) unlink() on such beasts. Welcome to fun. And no, it's not
> rmdir() - here we are removing non-empty object.
> c) rename() of normal file to such animal and vice versa.
> d) rename() of directory <<--->>
> e) propagation of chmod() results
> f) _if_ we do unlink() - what should happen with
> delete-upon-the-last-iput() semantics?
I think the above are non-VFS issues to a large degree, and will depend on
how the low-level filesystem handles things.
For example, I don't think a filesystem would want to allow the rename
case. The VFS layer doesn't need to know about this: the filesystem would
just return "EINVAL" or something. Same goes for "link()". And same goes
for "chmod()".
The _interesting_ thing is what the filesystem does with the "struct
inode", for example.
I suspect that a filesystem that supports resource forks will just have
the same inode for the whole thing. In effect, they would look somewhat
like hard links to a normal UNIX application. But the filesystem would
save the resource-specific informaiton in the "dentry->d_private" field.
Alternatively, the filesystem might decdie to use separate inodes. The VFS
layer probably doesn't care.
> Care to give semantics for operations in the list above?
Depending on how you want to do the implementation, you can do different
things. I suspect a lot of things just won't be allowed. For example,
doing a chmod() on a fork might do different things - ranging from "refuse
to allow any changes except on the default fork" to "having different
permissions on different resources".
We've had similar issues with the MS-DOS filesystem just because it
doesn't have some of the attributes at all. You can think of resource
forks as having the same kind of "incomplete" file semantics. This is not
a new problem in that sense.
And after all, this to a large degree depends on what the low-level
filesystem capabilities are. A low-level filesystem might easily have
different permissions for different resources. Not very likely, but not
impossible.
Imagine a filesystem that carries a "validation cookie" with every file,
for example. The whole point of such a validation cookie would be that
even the owner of the file couldn't change it - and copying the file would
not be able to copy the validation cookie.
Basically, the VFS layer cannot handle all of these issues 100% right now.
However, none of them look like fundamental problems, and they seem to
fall into the category of "we've never done that before, so we don't have
the support for it yet, but it's a SMOP".
Famous last words.
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:28 EST