W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [whatwg] Intent of the FileSystem API

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 28 Feb 2011 21:21:57 -0500
Message-ID: <AANLkTi=4igq1JYXAZ6vyJEsE9W7aMiqJyDyXRDCXw+Lf@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: Charles Pritchard <chuck@jumis.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Feb 28, 2011 at 7:41 PM, Eric Uhrhane <ericu@google.com> wrote:

> Sorry--I meant to push this over to public-webapps, as Ian suggested.
> [+cc public-webapps, whatwg->BCC]
>

Currently (reviewing for context), the spec tries to reach "filename
consistency" (only allowing filenames to be used which can be used
consistently on all browsers) by restricting filenames to the lowest-common
denominator.  With this path length issue, I don't think that approach is
correct, since it seems like everyone's going to have to implement path
virtualization anyway.

Based on that, I'd like to suggest a model change:

- Only place basic restrictions on filenames, giving the broadest set of
filenames that are generally supported (eg. no slashes, nulls, and some
reasonable length limits).
- For sandboxed directories, it's guaranteed that all legal filenames are
permitted, whether or not the local filesystem supports them.  If the native
filesystem isn't capable of supporting all legal filenames, virtualization
is required.
- For "mounted" directories, no guarantee of "filename consistency" is made:
you can create filenames on some systems that aren't allowed on others.
Filenames invalid on a particular system raise an exception.

This gives filename consistency for sandboxed directories without applying
quirks of all operating systems to users of all other operating systems.

This expressly gives no guarantee of filename consistency for "mounted"
directories (which don't exist yet, of course).  As we talked about before,
I think this is critical when dealing with directories shared with native
applications.  If the user creates "hello?.txt", then a web app version of
gzip must be able to create "hello?.txt.gz" if the system can do so.
Similarly, if the user creates "family photos: Bill.jpg", a web app image
resizer must be able to create "family photos: Bill (thumbnail).jpg".

(I'm not trying to get into the particulars of "mounted" directories now,
but I needed to mention them to explain how this suggestion fits together,
since directories interacting with native applications can't be
virtualized.)


On Mon, Feb 28, 2011 at 7:59 PM, Charles Pritchard <chuck@jumis.com> wrote:
> There are certainly issues in old copies of windows, but I think they've
> been addressed since.

It still happens in Win7, even in Windows Explorer.  I'm pretty sure this is
just PATH_MAX, which hasn't changed.

-- 
Glenn Maynard
Received on Tuesday, 1 March 2011 02:22:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT