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: Tue, 1 Mar 2011 14:37:40 -0500
Message-ID: <AANLkTimLP8Z3=Baim-0Psmj2h+5eEamFGhr3iOEqWosy@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 Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane <ericu@google.com> wrote:
> What would you suggest for limitations?  If we're requiring
> virtualization, it seems to me that we could be quite liberal.

I'd suggest only the restrictions that are required for the API: no
"", ".", "..", and no filenames containing forward slashes.

Maybe some fairly high filename component limit (NAME_MAX) for sanity;
maybe 4k (in UTF-16).

Maybe disallow nulls; I'm not sure if this is special enough to
actually need to be in this set.

I think the "5000 entries per directory" limitation should also go
away.  Virtualization hides any local directory
limitations--presumably files on disk wouldn't mirror the virtualized
directory structure.

(By the way, I'm not sure from the spec which error code is used for
invalid filenames.  Also--though this section may be irrelevant if you
go with this approach--section 8 says "This section is non-normative."
and then contains normative requirements.)

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

Sure, I don't think anyone predicted OS-related problems that were
quite that difficult to mask with filename restrictions.  (It feels
like I should have thought of it, too, since I've hit the this issue
several times natively when extracting archives with long
filenames...)

-- 
Glenn Maynard
Received on Tuesday, 1 March 2011 19:38:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC