Re: [File API: FileSystem] Path restrictions and case-sensitivity

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