Messages in this thread | | | Subject | Re: NTFS-like streams? | Date | Sun, 13 Aug 2000 22:42:20 -0400 | From | Horst von Brand <> |
| |
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. But this kind of crap obviously won't be reasonably mappable to honest filesystems, and much less mappable to other dishonest ones.
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, atomicity or file-like properties are important 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?
- Is it enough to manage non-POSIX semantics on alien filesystems by specialized userland tools? How important is said manipulation? How important will it be? 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).
- 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).
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, 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.
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), and if possible that it is at all worthwhile to do it in the kernel, and not by special tools for each case. -- 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/
| |