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 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC