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

> > Eurgh. Do it userside: the kernel provides enough of an API to do it.
> No it doesn't. That's the point.

It does - that's the point.

> Unless I'm mistaken, in which case would you be so kind as to point me at
> an example of userspace code which accesses HFS forks,

Netatalk does, apparently. HFS forks are certainly accessible to userspace
without ANY changes to the API.

> NTFS streams,

Off-hand, I don't know of any code which uses them. The NTFS driver could
certainly allow access to them without ANY VFS or API changes at all,
though, as I have explained before.

> as well as HPFS and BeFS EAs, without resorting to direct manipulation
> of the device (hence rendering any compatibility with filesystem
> implementation changes null and void)?

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.

> If so, then I'm happy, because this is what I want. If not, then it'd seem
> you're arguing against the very concept of this, not the method of
> interfacing with filesystems which support it already.

It can be done, and in HFS's case already is. No API change needed.

> While "Are streams/forks a good idea?" is a very interesting topic with
> plenty of arguments both for and against, it isn't the topic at
> hand.



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.069 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site