Messages in this thread | | | Subject | Re: NTFS-like streams? | Date | Mon, 14 Aug 2000 08:36:59 -0400 | From | Horst von Brand <> |
| |
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/
| |