Messages in this thread |  | | Date | Mon, 21 Aug 2000 00:24:48 +0100 (BST) | From | Mo McKinlay <> | Subject | Re: abstract file (support multi-part) |
| |
Today, James Sutherland <jas88@cam.ac.uk> wrote:
> Netatalk does, apparently. HFS forks are certainly accessible to userspace > without ANY changes to the API.
> HFS and NTFS, yes: no changes needed at all. HPFS's EAs aren't a concept > VFS was really designed to handle; again, though, the HPFS driver can > allow userspace to access EAs as a block of data via VFS without any API > changes at all.
> It can be done, and in HFS's case already is. No API change needed.
Right at the beginning of this thread, Linus said (in three different messages):
> However, I don't think it's a very nice user-interface to force the > "files with resource forks are always seen as directories" notion upon > users. It defeats the _nice_ properties of resource forks (ie not > forcing people to be aware of the secondary data).
The same clearly applies to a stream being a file in the traditional sense as well.
> The best we can do is to have _sane_ semantics for supporting such > filesystems. Sane and usable. Things like "fd_open()" make sense even > without resource forks - it's kind of a private extension of the > notion of "current working directory", after all.
And finally:
> Alan, do you really mean to say that every filesystem that has > resource forks shoul dsolve the problem over and over again, and in > different manners?
Which is what you seem to be suggesting above.
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |