lkml.org 
[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: abstract file (support multi-part)
On Mon, 21 Aug 2000, Mo McKinlay wrote:
> 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.

No. "Secondary" streams will be clearly identifiable as such; new versions
of tools (ls, GUI file managers etc) can default to ignoring these files
as needed. This is not true of the hideous "files become directories"
kludge.

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

This seems a bit out of context - these aren't resource forks.

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

The filesystem in question (NTFS) has a completely different approach.
There is an obvious and correct way to implement NTFS-style streams under
Linux - the way I'm advocating. HFS's resource forks are already
implemented - but they are a completely different approach to a completely
different problem.

NTFS's streams are not HFS resource forks, although they can be used to
emulate the latter if needed. Similarly, NTFS streams are NOT OS/2 HPFS
EA's - NTFS supports them as well, and they are not related in any way to
streams.

Three completely different systems: HFS resource forks, NTFS streams,
HPFS/NTFS Extended Attributes. The first has already been dealt with; the
second has a very obvious solution. The latter needs a bit more thought -
if we really need to support this rather odd HPFS feature?


Apart from anything else, whatever solution you take for NTFS will end up
being mapped (in userspace if necessary) into my approach for almost every
use of NTFS streams. Why reinvent the wheel?


James.

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

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