On Thu, Aug 18, 2011 at 8:09 PM, Dave Reisner <[email protected]> wrote:
Commit message explanation would be nice, as until I actually looked at the code, I didn't realize this only applied if we were not in the CURLE_OK case (e.g. some sort of download failure). A 200 OK with 0-byte response will not get deleted, correct? > Signed-off-by: Dave Reisner <[email protected]> > --- > Fewer .part files left behind... > > lib/libalpm/dload.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c > index f03fabd..4b6ce74 100644 > --- a/lib/libalpm/dload.c > +++ b/lib/libalpm/dload.c > @@ -266,6 +266,7 @@ static int curl_download_internal(struct dload_payload > *payload, > long timecond, respcode = 0, remote_time = -1; > double remote_size, bytes_dl; > struct sigaction sig_pipe, sig_int; > + struct stat st; > /* shortcut to our handle within the payload */ > alpm_handle_t *handle = payload->handle; > handle->pm_errno = 0; > @@ -338,6 +339,10 @@ static int curl_download_internal(struct dload_payload > *payload, > case CURLE_ABORTED_BY_CALLBACK: > goto cleanup; > default: > + /* delete zero length downloads */ > + if(stat(tempfile, &st) == 0 && st.st_size == 0) { > + payload->unlink_on_fail = 1; > + } > if(!payload->errors_ok) { > handle->pm_errno = ALPM_ERR_LIBCURL; > _alpm_log(handle, ALPM_LOG_ERROR, _("failed > retrieving file '%s' from %s : %s\n"), > -- > 1.7.6 > > >
