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.
Eric
[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1031.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0704.html
