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

On Fri, May 6, 2011 at 9:38 AM, timeless <> wrote:
> Consider the case where a user is trying to build a "web site", where
> they might have "resources" which are accessible via another resource
> (e.g. a web page). I'd much rather that we not make it easy for users
> to have Hi, hi, Hï, Hı as distinct files, I don't think they're well
> served by doing this. If someone gets a collision then something
> should automatically pick or ask for a different name, this might in
> rare cases be the user, but on average it'll just be the code itself
> picking something like hi_1, which will be fine.

This can be solved at the application layer in applications that want
it, without baking it into the filesystem API.

>> 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.
> This point has no merit. Eric's proposal says "let's support things
> which won't work on FAT anyway". As such, anything which tries to
> serialize to fat and have the resulting content "work" would have to
> apply a filter -- just as "save as web page complete" munges things
> today.

I don't know what you're talking about.  We're not talking about
serializing to FAT, we're talking about case-sensitivity within
virtualized filenames.

Again, if filenames are case-insensitive, then the API will work
differently on a Turkish system than other systems, as I described, in
a way that's guaranteed to cause interop failures.  This point stands.

Glenn Maynard

Received on Friday, 6 May 2011 17:22:32 UTC