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

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

From: Eric U <ericu@google.com>
Date: Tue, 3 May 2011 17:58:30 -0700
Message-ID: <BANLkTi=-o-dgzdOC2+hzWFE+NbO1NEcB_A@mail.gmail.com>
To: Web Applications Working Group WG <public-webapps@w3.org>
Cc: Charles Pritchard <chuck@jumis.com>, Glenn Maynard <glenn@zewt.org>, Kinuko Yasuda <kinuko@google.com>
I'd like to bring back up the discussion that went on at [1] and [2].

In particular, I'd like to propose a minimal set of restrictions for
file names and paths, punt on the issue of what happens in later
layers of the API, and discuss case-sensitivity rules.

For the sandboxed filesystem, I propose that we disallow only:
	* Embedded null characters [will likely break something somewhere]
	* Embedded forward slash (/) [it's our delimiter]
	* Embedded backslash (\) [will likely confuse people if we permit it]
	* Files called '.' [has a meaning for us already]
	* Files called '..' [has a meaning for us already]
	* Path segments longer than 1KB [probably long enough, and I feel
better having a limit]
...and explicitly support anything other than that.  I'm not proposing
a maximum path length at this time...perhaps we should just say "MUST
support at least X" for some large X?

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.

[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1031.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0704.html
Received on Wednesday, 4 May 2011 00:59:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC