cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Javier Puerto <jpue...@gmail.com>
Subject Re: File-transfer: delete target file on process error
Date Tue, 17 Jun 2014 08:18:46 GMT
2014-06-16 17:01 GMT+02:00 Andrew Grieve <agrieve@chromium.org>:

> I think this behaviour has been around for a while, and makes sense in the
> majority of cases.


Yep, I did a "git blame" and this fragment of code was there from the
beginning.


> Best practice is to download to a temporary location,
> and then upon success move the file to its final spot.
>

Yes, this is what I will have to do at the end. The thing is that I want to
avoid a double step process. Anyway I'm still thinking that a hard coded
and undocumented behaviour is not a good practice neither, mostly because
there's the tools for the developer to act as he needs with the success or
error callback. It's about flexibility.


>
> That said, I think it'd be fine to add an option for not delete on error.
>

It seems like the file transfer download is oriented to use a temporary
directory so it's fine for me as is (keep it simple). I think that an
explanation in the plugin documentation should be great so everyone can
figure how to use the download.

About the issue CB-6928, my patch it's not valid for me as I will use the
temporary directory now and probably for everyone so I will have to cancel
the pull request. The problem is still there but I wonder how can we fix it
if the success callback argument is an "Entry" object, the ideal should be
to be able to communicate the caching status. I will change the patch to
use the error callback to communicate the caching status, it's not an error
but I don't see other way. I will add also the documentation for the new
caching status code and open a new pull request.


>
>
> On Mon, Jun 16, 2014 at 5:39 AM, Javier Puerto <javier@apache.org> wrote:
>
> > Hi Cordova developers,
> >
> > I'm creating a system to download/update several resources from a server
> to
> > the device and I've observe a behaviour that breaks my use case.
> >
> > After fix the issue CB-6928, I'm able to download/update all the
> resources
> > without problems. My next test was to try to download the resources but
> > with no server response (stopped). I've found that the plugin is deleting
> > my target file silently because there's was an error.
> >
> > I think that the developer should be the responsible to delete or leave
> the
> > "corrupted" file because the file-transfer plugin already communicates
> the
> > error, I don't think that the hardcoded behaviour is a good solution.
>  What
> > do you think?
> > I can open a new issue and provide the patch and test case (Android only)
> >
> > Best regards.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message