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@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.