On 12 Aug 2000, Linus Torvalds wrote:
> Suggestions welcome. What's your interface of choice for a filesystem
> like HFS that _does_ have resource forks? Whether you like them or not
> is completely immaterial - they exist.
>
> And usability concerns _are_ real concerns. I'm claiming that the best
> interface for such a filesystem would be
>
> open("file", O_RDONLY) - opens the default fork
> open("file/Icon", O_RDONLY) - opens the Icon fork
> open("file/Creator"...
>
> readdir("file") - lists the resources that the file has
>
> 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_.
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.
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?
That's more or less it. Oh, and have fun with link(2) if some filesystems
that have forks support it. If you've got a way to handle multiple links
to object that has children - I'll be glad to hear it.
Care to give semantics for operations in the list above?
-
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