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

On Wed, May 4, 2011 at 3:58 AM, Eric U <ericu@google.com> wrote:
> Regarding case sensitivity: I originally specced it as
> case-insensitive-case-preserving to make it easier to support a
> passthrough implementation on Windows and Mac.  However, as
> passthroughs have turned out to be unfeasible [see previous thread on
> path length problems], all case insensitivity really gets us is
> potential locale issues.  I suggest we drop it and just go with a
> case-sensitive filesystem.

I'm somewhat worried about the case where two files have nearly the
same name and the user gets confused.

It's bad enough that one of my phones doesn't show file extensions and
its text editor generates files that are either HTML or Plain
(actually, i can't remember the actual file extensions, but the point
its it generates "rich text" and "plain text" - and can
promote/demote). So I generally have a file <notes> and a file <notes>
and I can't tell them apart and I can't remember which one I want (the
edit date is often the same for both and one has the content I want
and one is the accidental version from before I switched file
formats).

While case folding is expensive and painful, do we have any use cases
for allowing similarly named files beyond "enabling the user to
conflate them"?

Consider the following two items:
gооgle.com
google.com

- try loading them in a web browser -- oddly my web browser tells me
that the second one is misspelled :)

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. As we're proposing file names that
are longer than most users are likely to use by default, we can
include datestamps (timeless unless collisions happen) to disambiguate
user generated collisions via a browser side import -- if such a
feature is provided at all).

Received on Thursday, 5 May 2011 07:43:35 UTC