W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 5 May 2011 08:16:40 -0400
Message-ID: <BANLkTi=EwgSyJZ3U33fVjCVz2acO1j0pYg@mail.gmail.com>
To: timeless <timeless@gmail.com>
Cc: Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Charles Pritchard <chuck@jumis.com>, Kinuko Yasuda <kinuko@google.com>
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.
(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.

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.

-- 
Glenn Maynard
Received on Thursday, 5 May 2011 12:17:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT