On Sat, May 7, 2011 at 9:24 PM, timeless <timeless@gmail.com> wrote: > On Fri, May 6, 2011 at 8:22 PM, Glenn Maynard <glenn@zewt.org> wrote: >> This can be solved at the application layer in applications that want >> it, without baking it into the filesystem API. > > I wasn't talking about baking it into the api, i meant that the > application using it could write such code. You're talking about baking case-insensitivity into the API. I'm saying applications can implement case-sensitivity if it's desired for their use case, instead of forcing it on everything despite the problems it causes. > you raised an issue involving if something were serialized, and i > noted that the serialized case is already unhappy with eric's > proposal. I didn't say anything about "serializing to FAT"--I didn't mention FAT at all. I said: > It's a serious problem if this isn't interoperable. If filenames are > case-insensitive and honor the locale, then people are going to save > files as "IMAGE.JPG" and access them as "image.jpg", and it'll work > everywhere except on Turkish systems. If *this API's* concept of filenames is case-insensitive, then "IMAGE.JPG" and "image.jpg" represent the same file on English systems and two different files on Turkish systems, which is an interop problem. > case 1: > file is '<dotless-i>', file reference is '<dotted-i>', the generated > content does *not* work on your *average* system. someone notices > relatively quickly. If you create "IMAGE.JPG" (dotless-I) in one part of your code and then refer to it elsewhere as "image.jpg" (dotted-i), it *does* work on an average (non-Turkish) system if filenames are case-insensitive. Only when someone tries to use this same code on a Turkish system will it fail, where "I" and "i" are different characters. -- Glenn Maynard
Received on Sunday, 8 May 2011 02:44:53 UTC