Re: [whatwg] Intent of the FileSystem API

On Mon, Feb 28, 2011 at 6:21 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

Indeed.

> 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).

What would you suggest for limitations?  If we're requiring
virtualization, it seems to me that we could be quite liberal.

> - 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.)

Yes, and I'm finding myself agreeing with you, although I've argued
the other side in the past.  Sometimes you just have to try
implementing it to figure out what's not going to work.

> 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 18:14:38 UTC