- From: イアンフェッティ <ifette@google.com>
- Date: Thu, 9 Sep 2010 00:37:09 -0700
- To: Kinuko Yasuda <kinuko@chromium.org>
- Cc: Eric Uhrhane <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
- Message-ID: <AANLkTinpivkbPkBzEXK1_uM+7agKmwZ74aa7yDQemgZz@mail.gmail.com>
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? 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 >>> > >>> >> >> >
Received on Thursday, 9 September 2010 07:37:41 UTC