On Wed, 23 Jan 2008, Theodore Tso wrote:Well, it demonstrates that (a) the OS and (b) _perl_ don't mangle filenames on non-HFS+ filesystems. The problem is that since most native applications *expect* that name mangling, they'll probably do name mangling of their own (internally) just to compare the names! So I would not be surprised if the globbing libraries, for example, will do NFD-mangling in order to glob "correctly", so even programs ported from real Unix might end up getting pathnames subtly changed into NFD as part of some hot library-on-library action with UTF hackery inside. Things like the finder etc, which must be very aware of the fact that filenames get corrupted, would presumably internally always convert everything they get into NFD in order to compare names from different sources. And as part of that, programs may well corrupt the name before they then use it to create a pathname. The fact that your perl program works under NFS, but creates NFD on a VFAT volume, does imply that they probably used at least some of the same routines they use in HFS+ for VFAT. Not entirely surprising: doing case insensitive stuff with Unicode is nasty code, so why not share it (even if it's then incorrect for FAT).. Piece of crap it is, though. Apple has painted themselves into a nasty corner there. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Michael Opdenacker | [PATCH] x86: fix unconditional arch/x86/kernel/pcspeaker.c compiling |
git: | |
| David Miller | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
