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

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.

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.

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:15:24 UTC