On Thu, Aug 18, 2011 at 8:09 PM, Dave Reisner <d@falconindy.com> 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 <dreisner@archlinux.org> --- 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