[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NTFS-like streams?
On Sun, 13 Aug 2000, Horst von Brand wrote:

> Alexander Viro <> said:
> > On Mon, 14 Aug 2000, James Sutherland wrote:
> > > > Sorry? I do rename("foo","bar"); Suddenly foo:splat becomes bar:splat.
> > > > Which of them should I drop?
> > > What has that got to do with short filenames?
> > Sigh... OK, I really need more coffee. Let me put it that way: this
> > behaviour (names migrating as the result of operation on different names)
> > has really nasty implications. On VFAT we had it due to short names. Your
> > proposal on NTFS promises the same sort of fun. Experience from dealing
> > with the shortname problems on VFAT makes me rather unhappy about your
> > proposal.
> 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 :-)

> But this kind of crap obviously won't be reasonably mappable to honest
> filesystems, and much less mappable to other dishonest ones.

Yup. It's HORRIBLE. Apart from anything else: If I copy one of these
"directories" to ext2 and back, how does NTFS "know" the "directory" it's
being handed is really supposed to be a file on NTFS, but a directory on
ext2? And how many sickbags will the users need when they see this?

> I see Linus' point: If we want to support NTFS, and so on, we must do it
> right (i.e., preserving full semantics) as far as possible. As for Linux
> growing such warts on its own, I very much doubt it after this second (or
> is it third?) round of this flamewar. It just doesn't fit well with the
> general POSIX model, and where it fits it is just a funny kind of
> directory, which is absolutely pointless IMVHO.
> 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.

> atomicity or file-like properties are important here.

File-like properties:

1. They are files.
2. They look like files.
3. They smell like files.
4. They taste like files.

The only distinction is that they share the [acm]time and permissions with
one or more other files of a similar name, under NTFS.

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

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

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

Not critical, but very desirable.

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

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

> AFAIKS, this is mostly a non-issue, as long as tar(1) and similar tools get
> a handle they can use to get/create the bytestream that constitutes the
> "structured" file in some way,

Hang on - "structured" files?! Where on earth did that spring from? We're
talking about file-system file data attributes (i.e. files).

> which can very well be different from filesystem to filesystem (and
> will have to be, you are trying to map non-POSIX to a sane POSIX
> approximation here in the first place). Or just give up, and give
> users NTFStools just like e2fstools to dump, restore, fsck, and
> whatever. We are doing so even for _native_ Linux filesystems! Please
> note that "Changing tar(1) is a three-liner with this kernel
> super-hack" just doesn't cut it: Portability from/to Linux has made it
> great, and there are just way too many such "three-liners" that would
> have to be designed, installed, tested, and then rammed down the
> throats of the respective maintainers, and kept up to date for the
> benefit of a tiny minority.

My approach avoids the need for ANY changes to tar & co. Much saner.

> Sure, to get it done in a sane way would be a very cool hack. I just doubt
> it is possible (too many different ideas of what precisely "structured
> files" are all about are floating around),

Structured files are a completely different issue - probably a userspace
one, too. FS-level streams are kernel-side, and another matter entirely.

> and if possible that it is at all worthwhile to do it in the kernel,
> and not by special tools for each case.

I don't see the need for that sort of thing yet, but that's another issue


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 13:58    [W:0.195 / U:7.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site