[pacman-dev] [PATCH] Handle .part files that are the size of the correct package

[Andrew Gregory]

On 11/15/19 at 11:46pm, Allan McRae wrote:
> In rare cases, likely due to a well timed Ctrl+C, but possibly due to a
> broken mirror, a ".part" file may have size at least that of the correct
> package size.
> 
> When encountering this issue, currently pacman fails in different ways
> depending on where the package falls in the list to download.  If last,
> "wrong or NULL argument passed" error is reported, or a "invalid or
> corrupt package" issue if not.
> 
> Capture these .part files, and remove the extension. This lets pacman
> either use the package if valid, or offer to remove it if it fails checksum
> or signature verification.
> 
> Signed-off-by: Allan McRae <allan at archlinux.org>
> ---
> 
> To test this patch do:
> 
> mv /var/cache/pacman/pkg/xz-5.2.4-2-x86_64.pkg.tar.xz{,.part}
> pacman -S xz
> 
> 
> Having to run _alpm_filecache_find() in find_dl_candidates() on all packages that
> have download size of 0 is not given we run already it in compute_download_size().
> However, we would require storing it in the alpm_pkg_t struct and I don't think
> that overhead was worth it.  However, we then call _alpm_filecache_find() in 
> check_validity() and load_package()...  Still probably not worth it!
> 
>  lib/libalpm/dload.c |  6 ++++++
>  lib/libalpm/sync.c  | 14 ++++++++++++--
>  2 files changed, 18 insertions(+), 2 deletions(-)

ACK.  This does cause one minor oddity: if the .part is the only
package being installed, pacman prints "::Retrieving packages..." but
then doesn't actually download anything.