Messages in this thread | | | Subject | Re: JFS default behavior | From | Valdis.Kletnieks@vt ... | Date | Mon, 16 Feb 2004 03:54:07 -0500 |
| |
On Mon, 16 Feb 2004 09:30:41 +0100, Nicolas Mailhot said:
> You're assuming the situation is merely a iso8859-1 to utf-8 migration. > Far from it. The core problem is everyone damn wrote what it pleased him > without considering future readers.
Given the fact that there isn't in general any way for the kernel to know what was intended, I don't see how any kernel policy other than "NUL and / are special, but if you use anything other than UTF-8 it will eventually come back to haunt you" can possibly be made to work.
For that matter, I have seen actual production code that intentionally created fairly deep directory trees and terminal file names that were basically hashes written in radix-254 and blatted out in binary. Lots of them. The original problem report I got was along the lines of "We installed XYZ, and the file system appears corrupted - ls -R weird the screen out, and 'find | wc -l' is 127,000 different than what 'df -i' reports".
I was ready to strangle the guilty party - radix-64 wouldn't have been a big efficiency hit and at least the uuencode/base-64 charset doesn't weird your terminal out. :)
So it's not even always possible to make the assumption that the filename is supposed to make sense in *any* charset. This one requires fixing in some combination of userspace and meatspace....
[unhandled content-type:application/pgp-signature] | |