Re: [whatwg] Intent of the FileSystem API

On Tue, Mar 1, 2011 at 11:37 AM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

That makes sense.

> 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 like it, though, as allowing nulls in strings is likely to lead to user error.

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

Right.

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

The non-normative flag is only supposed to be for the next paragraph,
not the whole section.  Thanks--I'll fix that when I rewrite that
section.

>> 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 20:18:05 UTC