lkml.org 
[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: NTFS-like streams?
Date
From
James Sutherland <jas88@cam.ac.uk> said:
> On Sun, 13 Aug 2000, Horst von Brand wrote:

[...]

> > The idea is that foo:splat is directory:file (with a funny, FS-specific
> > separator) makes most sense.

> Except that it isn't a directory. Good start :-)

It is the closest match to POSIX I can think of.


[...]

> > So, there are some points to clarify:
> >
> > - What are the exact kinds of these (to us alien) constructions that are
> > around? Semantics, including size limitations,

> None. They're files.

What is a file? The bundle, or each individual piece? [I infer you are
talking only about WinNT's streams here]

[...]

> > - For what use is the support intended? To be able to serve files from
> > alien filesystems to machines expecting the same alien filesystem only?

> More than that: porting NT apps to Linux will need this support locally.
> The NT apps will expect to be able to open these streams as
> "filename:stream", without screwing with
> pseudo-virtual-magic-directory-mount-point things.

That can very well be done with a special libc shim that knows the
structure of the underlying bytestream and roots around in it when told to
do so. The fun however only starts when somebody creates an Unix file
called example:streamy that has streams inside ;-)

> > - Is it enough to manage non-POSIX semantics on alien filesystems by
> > specialized userland tools?

> No. If possible, the normal tools should work as expected.

Sure, that would be ideal as far as just the use of the alien filesystem
goes. Problem is that "as expected" is a tenuous concept at best: If I copy
one of these objects, do I copy it all? Why or why not? What if I just copy
one subobject out of it? One subobject into another object? A plain file
into a subobject? If the plain file is itself structured, what happens?
Overwrite a subobject? What happens to the object if I change permissions
to a subobject? Delete it? Change its name? Create a (hard or symbolic)
link to it? The "works as expected" is only "expected" in POSIX for the
objects POSIX mandates, and even there there are gotchas for the unwary...

But that isn't the only criterion: Does this break other filesystems, or
interoperability with them? Does this work only on specific alien
filesystems, or does it work across the board (even across _different_
alien filesystems!)? Note that to support this is a _very_ mayor pain (if
it is indeed possible), and not doing so looses one of Unix' central
advantages, its uniformity across the board. Does it break standard tools,
do they need upgrading? How much bloat does it induce on the kernel (no,
it won't be "just support in the filesystem that uses it", the whole VFS
layer will have to be adjusted to fit)? What are the security implications
on tools that _don't_ know (even don't want to know) about this stuff?
Does it break time-honored ways of thinking about files in Unix (from the
user's, the sysadmin's and the programmer's perspectives)? All these are
cons, what exactly are the pros? Do they weigh up the cons with enough of
an overall win?

> > How important is said manipulation? How important will it be?

> Not critical, but very desirable.

Why "very desirable"? I still haven't seen one convincing use for this that
can't be done (much more flexibly!) in userland, and without necessarily
bundling the extra data with the file in the first place. To make porting
Office2k to Linux easier isn't enough of a win in my eyes. Or any win at
all, for that matter.

> > To what real use is this stuff put on the alien
> > OSes? Is is important, or just a "cool" feature looking for (mis)use?
> > (I'm assuming Linux will stay POSIX in its core, so native Linux
> > applications for this is just a non-issue).

> I would doubt that: there are reasonable uses for it, and I can't see what
> is "non-POSIX" about this feature.

Come on, in POSIX a file is a bytestream without further structure. Even
devices are forced into this mold for uniformity.

> > - How many people think they will have a real-world use for such a feature?
> > AFAIKS, the uses are either in some emulator for the alien OS (which will
> > have to handle it in the alien way anyway, and is no issue to Linux), or
> > in clones of alien tools that use this stuff, and they will have to pick
> > the file appart on their own anyway (probably through a filesystem/alien
> > OS specific library).

> s/clones/ports/. Having these features will make porting much easier. They
> are also useful features in their own right.

Useful for what? And again, _what_ reasonable uses? Do they outweight the
unreasonable uses handsomely enough to make the whole mess worthwhile?
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile +56 32 672616

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