In article <7jlEMswXw-B@khms.westfalen.de>,
Kai Henningsen <kaih@khms.westfalen.de> wrote:
>torvalds@transmeta.com (Linus Torvalds) wrote on 12.08.00 in <8n4d8u$2ik$1@penguin.transmeta.com>:
>
>> 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
>
>That's a very different semantic from what MacOS does, and looks like a
>pretty poor match for the data structures involved.
Ehh.
The above is apparently _exactly_ that MacOS X does.
>To start with, the creator is an attribute much like the user and group
>under Linux, and is *not* implemented via resource forks. So it really
>doesn't belong here, it belongs in a fs-specific stat() extension
>(possibly an ioctl).
Sure. Forget the naming: I don't actuall yknow what the different
resources are on Macs. Think of if as the generic interface.
>Then, the structure is either low-level
> open("file/resourcefork", O_RDONLY)
>- which you *can* do on MacOS (just with a different function instead of a
>different name) - or for individual resources, it's more like
> open("file/ICON/-16383", O_RDONLY)
>Yes, there's a hierarchy involved.
Hierarchies make sense. Good for them. If you create resoruce forks, you
might as well make them hierarchical.
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:30 EST