Messages in this thread |  | | | Date | Mon, 14 Aug 2000 09:43:09 +0100 (BST) | | From | James Sutherland <> | | Subject | Re: NTFS-like streams? |
| |
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/
|  |