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

On 5/8/2011 12:50 PM, timeless wrote:
> On Sun, May 8, 2011 at 5:44 AM, Glenn Maynard<glenn@zewt.org>  wrote:
>> If *this API's* concept of filenames is case-insensitive, then "IMAGE.JPG"
>> and "image.jpg" represent the same file on English systems and two different
>> files on Turkish systems, which is an interop problem.
> no, if the api is case insensitive, then it's case insensitive
> *everywhere*, both on Turkish and on English systems. Things could
> only be case sensitive when serialized to a real file system outside
> of the API. I'm not proposing a case insensitive system which is
> locale aware, i'm proposing one which always folds.

I've brought this up before: if the FileSystem API simply used OS/FS 
semantics,
whatever they are, authors can decide when and what they're going to do with
errors and the like, at a low level.

Were the IndexedDB spec in a more mature state, it would be much easier
from a developer perspective, to write a FileSystem API layer on top of it,
and use all of its goodness including arbitrary file names. The layer is 
reasonably
small, very easy to write in JS.

IDB allows me to easily stash store and search any kind of metadata I'd 
like to use, without hitting all the
down sides of file systems. It's easier to do file name searches, there's
no need to "clean up" empty directories. Metadata is side-by-side with 
the record.

I've used the FileSystem API as a standard naming model, so that I may 
still use
the same semantics when stashing files in IDB (or even websql, for old 
safari installs).

Given an IDB+Blob implementation, "bullet-proof" case folding may not be 
necessary.
I'd be using FileSystem API if I -do- want to interact with the user's 
file system in some way
  And in those events, I can chose my own folding heuristics.

These issues will still appear when we get an API that allows file 
system mounting / directory mounting.

A virtual FS as the backing for the filesystem API does not resolve that 
core issue.
It makes sense to encourage authors to gracefully handle errors thrown 
by  creating files and directories.
Such a need has already been introduced via Google Chrome's unfortunate 
limitation
of a 255 byte max path length.

The one take-away I have from that bug: it would have been nice to have 
a more descriptive error message.
It took awhile to figure out that the path length was too long for the 
implementation.

-Charles

Received on Sunday, 8 May 2011 20:05:44 UTC