- From: Eric Uhrhane <ericu@google.com>
- Date: Tue, 1 Mar 2011 12:17:20 -0800
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Charles Pritchard <chuck@jumis.com>, Web Applications Working Group WG <public-webapps@w3.org>
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