Re: Polished FileSystem API proposal

On Tue, Jul 16, 2013 at 8:53 AM, Eric U <ericu@google.com> wrote:
> On Tue, Jul 16, 2013 at 12:32 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Mon, Jul 15, 2013 at 11:02 PM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>>> Glad to see this proposal has a new draft.
>>>
>>> On Sat, Jul 13, 2013 at 9:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> Executive Summary (aka TL;DR):
>>>> Below is the mozilla proposal for a simplified filesystem API. It
>>>> contains two new abstractions, a Directory object which allows
>>>> manipulating files and directories within it, and a FileHandle object
>>>> which allows holding an exclusive lock on a file while performing
>>>> multiple read/write operations on it.
>>>>
>>>> It's largely modeled after posix, but because we've tried to keep it
>>>> author friendly despite it's asynchronous nature, it differs in a few
>>>> cases.
>>>>
>>>> There are opportunities for further simplifications by straying
>>>> further from posix. It's unclear if this is desired or not.
>>>>
>>>> Detailed proposal:
>>>>
>>>> partial interface Navigator {
>>>>   Promise<Directory> getFilesystem(optional FilesystemParameters
>>>> parameters);
>>>> };
>>>>
>>>> interface Directory {
>>>>   readonly attribute DOMString name;
>>>
>>>
>>> So neither File nor Directory has 'path' attribute but only exposes 'name'.
>>> It feels a bit inconvenient but is it intentional?
>>
>> It's something that I intended to add but forgot.
>
> Having the full path within the filesystem removes some of the
> security benefit of not allowing "..", doesn't it?  Conversely, is the
> path useful if you can't use it to manipulate anything above the
> current dir in the tree?

It removes some of the privacy benefits, but little of the security benefits.

It would at least be useful to let something like:

rootdir.get("foo/myfile.html").then(function(file) {
  assert(file.path + file.name === "foo/myfile.html");
});

The tricky thing is what to do if someone calls subdir.get(). Does
that return a File with .path set to a path relative to the root, or a
path relative to the subdir? If relative to the root, it does lose
some of the privacy benefits, but I'm not sure how important that is
within the sandbox. If relative to the subdir that means that you can
get two File objects representing the same file but with two different
paths. That's somewhat confusing.

Also note that we'd definitely never expose a path that goes outside
of the sandbox. I.e. the drag'n'drop or <input type=file> APIs should
never produce paths that contain directory names outside of the
directories that the user has attached to the page.

>> Keeping .name as just containing the leafname is probably the right thing to do.
>>
>> So we could introduce a .path property which contains the path within
>> the filesystem. The full filename would be .path + .name.
>>
>> And doing exactly the same for both Directory and File objects seems
>> like a good thing.
>>
>>> File object is meant to be a snapshot and becomes invalid after modification
>>> is made.
>>> Will Directory follow the same model?
>>> Say, if a Directory is acquired then moved (renamed) to another name, does
>>> the Directory object keep functioning or become invalid?
>>
>> Good question. I think the most sane way to implement the Directory
>> object is to internally keep a full path. Whenever an operation is to
>> be performed, we check if that full path still exists. If it doesn't,
>> the operation fails.
>
> Just to be clear: if you rename a Directory's parent, it goes stale
> and you can't use it.  But if you then create a new directory with the
> same name as the parent used to have, with a child of the right name,
> this object will again be valid.  The Directory is explicitly defined
> as referring to a specific path string.

Agreed.

/ Jonas

Received on Tuesday, 16 July 2013 18:42:12 UTC