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

On Wed, May 11, 2011 at 7:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wednesday, May 11, 2011, Eric U <ericu@google.com> wrote:
>> I've grouped responses to bits of this thread so far below:
>>
>> Glenn said:
>>> 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.
>>
>> Timeless replied:
>>> 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.
>>
>> You're proposing not just a case-insensitive system, but one that forces e.g. an
>> English locale on all users, even those in a Turkish locale.  I don't think
>> that's an acceptable solution.
>>
>> I also don't think having code that works in one locale and not another
>> [Glenn's "image.jpg" example] is fantastic.  It was what we were stuck with when
>> I was trying to allow implementers the choice of a pass-through implementation,
>> but given that that's fallen to the realities of path lengths on Windows, I feel
>> like we should try to do better.
>>
>> Glenn:
>>> This can be solved at the application layer in applications that want
>>> it, without baking it into the filesystem API.
>>
>> This is mostly true; you'd have to make sure that all alterations to the
>> filesystem went through a single choke-point or you'd have the potential for
>> race conditions [or you'd need to store the original-case filenames yourself,
>> and send the folded case down to the filesystem API].
>>
>> Glenn:
>>> 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.
>>
>> That limitation grew out of the OS-dependent passthrough implementation.  We're
>> fixing that right now, with this proposal.
>>
>>> 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.
>>
>> I apologize for that--it was an oversight.  If we can relax the restrictions to
>> a small set, it'll be more obvious what the problems are.  IIRC this problem was
>> particularly confusing because we were stopping you well short of the allowed
>> 255 bytes, due to the your profile's nesting depth.
>>
>> I'd like to obviate the need for complicated exceptions or APIs that suggest
>> better names, by leaving naming up to the app developer as much as possible.
>>
>> [segue into other topics]
>>
>> Glenn asked about future expansions of IndexedDB to handle Blobs, specifically
>> with respect to FileWriter and efficient incremental writes.
>>
>> Jonas replied:
>>> A combination of FileWriter and IndexedDB should be able to handle
>>> this without problem. This would go beyond what is currently in the
>>> IndexedDB spec, but it's this part that we're planning on
>>> experimenting with.
>>>
>>> The way I have envisioned it to work is to add a function called
>>> createFileEntry somewhere, for example the IDBFactory interface. This
>>> would return a fileEntry which you could then write to using
>>> FileWriter as well as store in the database using normal database
>>> operations.
>>
>> As Jonas and I have discussed in the past, I think that storing Blobs via
>> reference in IDB works fine, but when you make them modifiable FileEntries
>> instead, you either have to give up IDB's transactional nature or you have to
>> give up efficiency.  For large mutable Blobs, I don't think there's going to be
>> a clean interface there.  Still, I look forward to seeing what you come up with.
>
> Why not simply make the API case sensitive and allow *any* filename
> that can be expressed in JavaScript strings.

That's the way I'm leaning.

> Implementations can do their best to make the on-filesystem-filename
> match as close as they can to the filename exposed in the API and keep
> a map which maps between OS filename and API filename for the cases
> when the two can't be the same.

We're not speccing out anything outside the sandbox yet, and we've
decided that a pass-through implementation is impractical, so we don't
need this approach yet, there being no on-filesystem-filename.  It
certainly could work for the oft-mentioned "My Photos" extension, when
we get around to that.

> So if the pake creates two files named "Makefile" and "makefile" on a
> system that is case insensitive, the implementation could call the
> second file "makefile(2)" and keep track of that mapping.
>
> This removes any concerns about case, internationalization and system
> limitation issues and thereby makes things very easy for web authors.
>
> I might be missing something obvious as I haven't followed the
> discussion in detail. Appologies if that's the case.
>
> / Jonas
>

Received on Thursday, 12 May 2011 02:21:08 UTC