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

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.

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