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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:32 EST