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

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
>> >
>>
>
>