Re: New filesystem/directory API proposal

Thanks for the clarification.

I would argue that these are not critical use cases for a v1 spec, and
instead something we might want to consider in a later revision / extension.
My thinking is as follows:

1. I am most concerned about files that apps will try to programatically
create. Think of, for example, an email application that works offline and
stores files locally - would be tragic if it tried to create a file called
".Inbox/Drafts" or something like that, and this failed on certain platforms
but not others. That should be consistent.
2. For file managers, or really any app where a user is interacting with the
application to name a file, it seems that if they choose a name that doesn't
meet the restrictions, the app can then inform the user of the restrictions
and ask the user to pick a new name.
3. Even though it's not a top use case in my mind, I think you could still
implement something similar. I am assuming that if a file exists, you can
open it (get an enumeration from a FileList and use that to open the file).
It's just creating a new file that doesn't meet the restrictions that would
be problematic. The only case I can think of here is if a user tries to
rename <invalid> to <invalid>.bak or something. This seems like an extremely
rare case, and again, in such an interactive mode, you could inform the user
that that's an invalid filename and ask them to choose another. In some
later addition to the spec, perhaps we could offer more features from the
native filesystem (long(er) filename support, filenames that are constrained
only by the host OS, things like symlinks or hard links, etc.) But that
feels very much like a v2 effort.

2010/2/4 Arve Bersvendsen <arveb@opera.com>

> On Thu, 04 Feb 2010 21:28:08 +0100, Ian Fette (イアンフェッティ) <
> ifette@google.com> wrote:
>
>  I'm not sure I understand the problem. Let's say your use case is Midnight
>> / Norton / Total Commander (have no idea what any of these products are, I
>> assume AV?). Why do they need to write filenames that don't conform to the
>> restrictions posited above?
>>
>
> The tools were examples of completely generic file managers. I could just
> as well have said "Bash shell rewritten as a web application".
>
>
> --
> Arve Bersvendsen
>
> Opera Software ASA, http://www.opera.com/
>