lkml.org 
[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NTFS-like streams?
On Mon, Aug 14, 2000 at 05:30:59PM -0000, Christer Weinigel wrote:
> vonbrand@inf.utfsm.cl wrote:
> > I read it as "If it can be supported in a sane way, we should do it". This
> > is insane, as are all the other schemes I've seen discussed here. And
> > "supported somehow" leaves a lot of non-kernel options open: Special tools,
> > a compatibility library, ...
>
> So what is the sane way? There are three conflicting requirements for
> NTFS-like streams handling:
>
> 1. Don't break any existing tools, everything must behave exactly as
> it does today. tar must be able to make a complete backup.
>
> 2. Should allow old tools to work on the alternate streams (i.e.
> xv file/thumbnail.xpm).
>
> 3. Should not pollute the filesystem with extra files such as
> .AppleDouble, .fork, foo:resources or foo#tar/altstream.

(1) and (2) are things we can support in the VFS layer. (3) is
filesystem specific and, as such, is beyond the scope of this
discussion, IMHO. We are attempting to find a way of supporting
EA/NS in Linux itself so that the NTFS/HFS/BeFS functionality can
be fully supported in an independent manner.

> Another way is to implement a completely new API to access streams,
> for example:
> open_stream(fd, name) which returns a file descriptor
> create_stream(fd, name) which returns a file descriptor
> remove_stream(fd, name)
> enumerate_streams(...) which is similar to opendir/readdir

Linus suggested something like this with some trivial name changes.
This is, I thin, pretty close to what we're going to need when all
is said and done. This would allow a number of FS implementations to
work with the Linux kernel.

> This would work with no 1 and 3 - would not confuse any existing tools
> with a file/directory duality, but would also break no 2 by not
> allowing existing tools to work with the alternate stream data. And
> if one looks at the above functions, they are just a duplication of
> the normal open, create and opendir/readdir API's.

Part of the point of NS/EA is to allow programs that don't care about
them to use the files as they normally would, while allowing programs
that do know about them to exploit the extra functionality. As such,
making existing tools automagically work is probably not possible.
As Linus mentioned, tar can be extended. I'd go so far as to claim
the same for cp, mv, cpio, etc.

A Good Solution would, however, minimize the amount of extension
needed.

> but it has its problems with orphaning. The "different-API" model is
> clean, but means that just about every tool existing has to be
> rewritten to support alternate streams (for extended attributes, I
> belive this is the way to go, but for data streams it's not).

Building a clean, FS-independent interface is, IMHO, the way to go.

jf
--
John Franklin
Interlan Communications
franklin@interlan.net
ICBM: 35°45'17"N 78°44'11"W

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

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