Re: FileSystem API - overwrite flag for copy/move?

On Thu, Sep 9, 2010 at 12:37 AM, Ian Fette (イアンフェッティ) <ifette@google.com>wrote:

> I think recursive copy/remove is a very valid use case. As for overwrite,
> is a flag necessary? On most OSes you already get overwrite as the default
> behaviour (at least from APIs, many interactive UAs such as Explorer on
> windows will prompt), is there a compelling argument why it should be
> different for a web api?


Making overwriting mode default for copy/move sounds reasonable to me too.
 Especially if we allow recursive remove (and I think there would be more
need for this one) it'd look more consistent.

As for providing options, I was a bit concerned about the complexity in
programming with nested callbacks, but in this case it's not a big deal
(we'll need only two) and wouldn't be a problem.

I'm more concerned with recursive remove though.  The js code to do that
isn't very pretty.


On Thu, Sep 9, 2010 at 12:22 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>
>> On Thu, Sep 9, 2010 at 12:12 AM, Kinuko Yasuda <kinuko@chromium.org>wrote:
>>
>>> On Tue, Sep 7, 2010 at 6:12 PM, Eric Uhrhane <ericu@google.com> wrote:
>>>
>>>> On Mon, Aug 30, 2010 at 9:27 PM, Kinuko Yasuda <kinuko@chromium.org>
>>>> wrote:
>>>> > Hi,
>>>> > I have a question about Entry.moveTo/copyTo behavior defined in
>>>> > the File API: Directories and System [1].
>>>> > Currently the API doesn't specify how Entry.moveTo() and copyTo()
>>>> should
>>>> > behave
>>>> > when a source entry is a file and there's *already* a file at the
>>>> > destination path.
>>>> > Should UAs overwrite the existing file at the destination path or not?
>>>> > Or maybe we should add an 'overwrite' flag to indicate if the script
>>>> wants
>>>> > to overwrite an existing file or not?
>>>>
>>>> I'm open to a flag.  We're already up to 4 parameters to each of those
>>>> methods, though...5 is a bit ungainly.  I'm concerned that we might
>>>> find another flag to add at some point, and we'd then be up to 6.
>>>> What about adding an flags object, as in getFile, to allow for
>>>> expansion?
>>>
>>>
>>> Adding a flag or flags object (suppose the other thread about Flags will
>>> be settled) sounds good to me.
>>>
>>> Or I think it's also ok to explicitly disallow overwriting copy/move,
>>> i.e. specify that 'it is an error to copy or move a file or directory if
>>> there's already an entry'.  In this case it might be better to have another
>>> error code like ENTRY_EXISTS_ERR so that the user script can act
>>> differently.  (But in general having a handy option would make programming
>>> much easier in async context where every operation requires one or two
>>> callbacks.)
>>>
>>> If we're going to add 'overwrite' flag, there'll be a few more things to
>>> be made clear.
>>> For example I wonder how the overwriting copy/move should behave when
>>> there's already a **directory** at the destination path/name.
>>>
>>> Should the UA remove the existing directory and create a new entry at the
>>> same path?
>>> This sounds reasonable but it'll also provide a handy alternative way to
>>> remove a directory recursively.
>>>
>>
>> By the way how do you think about recursive remove?
>> Is there a reason (or past discussion) not to have recursive option in
>> remove?  (I mean, other than the fact that adding more and more options to
>> every method doesn't look very clean.)
>>
>> I found that it's not very easy to remove a directory when there're
>> children in it -- it requires multiple DirectoryReader.readEntries and
>> Entry.remove in a nested way.
>>
>> Thanks,
>>
>> Or should the UA create a new entry *under* the directory?
>>> This behavior doesn't sound like 'overwriting'.  The resulting path will
>>> be like 'destParentPath/name/name' which doesn't sound quite consistent with
>>> the spec either.
>>>
>>>
>>> > Similarly I wondered if we'd want to have a 'recursive' flag for
>>>> > moveTo/copyTo.
>>>> > I think for directories we can simply assume that the user wants to
>>>> > move/copy
>>>> > them recursively, but it might be good to add some notion about that
>>>> in the
>>>> > spec.
>>>>
>>>> How about I add a note indicating that directory copies are always
>>>> recursive?
>>>> I don't think we need anything for move.
>>>
>>>
>>> This sounds good to me.  Thanks!
>>>
>>>
>>>
>>>>  > Thanks,
>>>> > [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
>>>> >
>>>>
>>>
>>>
>>
>