- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 1 Mar 2011 14:37:40 -0500
- 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