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

On Thu, May 5, 2011 at 3:16 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, May 5, 2011 at 3:43 AM, timeless <timeless@gmail.com> wrote:
>> My argument is that we should favor:  'case preserving' + 'case
>> folding' + 'case insensitivity'.
>>
>> The virtual file system is going to be something which is mostly
>> controlled by the web app, so there should be minimal harm in telling
>> it that there's already a file with a given name -- it can load the
>> file, review its contents, and try to decide that it should suggest
>> the user use a more distinct name.
>
> You're thinking of this only in terms of one narrow, and in my opinion
> minor, use case: letting the user click "save" and enter a filename.

I'm not actually very interested in that case.

> (It's minor because a user saving a file usually doesn't want to do so
> to a virtualized, sandboxed filesystem that he can't access directly.
> That's the non-sandboxed use case; we're talking about the sandboxed
> case here.)  Much more important is bulk saving data, such as saving
> large amounts of downloaded data for a game.

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.

The proposal is case preserving, so if the file starts as Hı, that's
how it'd be returned via any enumeration or shown to the user. It just
means that if someone tries to stick an English "Hi" file into the
same place they'll be told to pick a new name. I do not think that
short names with colliding cases are better than forcing something
(probably a program) to pick better (yes, longer) names which do not
collide.

Yes, I'm asking to impose a constraint, it means that a game developer
can't be annoying and use each of Hi, hi, Hï, and Hı as distinct file
names. It's a design constraint, I do not think that a game developer
will suffer because of this constraint.

And before people complain that I've never had a use for dotless i and
can't have sympathy for people who do.... I've been to İstanbul and
have entire photo albums for it (including Topkapı Palace). I also
used to work for Nokia (Nokia's history involves a phone which didn't
support dotless i's, the result was a miscommunication and at least
one stabbing).

If file names are going to be generated programmatically, then a
constraint that says case preserving, case folding, case insensitive
should not be a significant hazard for anyone.

> 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.

Received on Friday, 6 May 2011 13:39:17 UTC