On Sun, 13 Aug 2000, Horst von Brand wrote:
> Alexander Viro <viro@math.psu.edu> 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
entirely.
James.
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:32 EST