[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: abstract file (support multi-part)

Today, James Sutherland <> 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

> 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 <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.093 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site