FS#73805 - libalpm fails to rename fully downloaded tempfiles
Attached to Project:
Pacman
Opened by David Phillips (phillid) - Wednesday, 16 February 2022, 04:51 GMT
Last edited by Allan McRae (Allan) - Wednesday, 16 February 2022, 04:57 GMT
Opened by David Phillips (phillid) - Wednesday, 16 February 2022, 04:51 GMT
Last edited by Allan McRae (Allan) - Wednesday, 16 February 2022, 04:57 GMT
|
Details
Summary and Info:
libalpm fails to rename fully downloaded (.part) tempfiles. The workaround is to rename the package tempfile to remove the .part from the end of its name. Steps to Reproduce: Use something like the attached script. Or manually execute the steps: 1. Ensure a completely downloaded package file is present in the pacman cache 2. Rename it, appending its name with `.part` 3. Try to install said package with -S and observe one of the error messages from above Extra: Inspecting the code, it looks like the chain of events is: 1. compute_download_size returns 0 when it finds our "complete" .part file: https://gitlab.archlinux.org/pacman/pacman/-/blob/90df85e9cf2fef38442345ea3171300399f3ca98/lib/libalpm/sync.c#L342 2. _alpm_filecache_exists misses and so find_dl_candidates still correctly marks the package for download: https://gitlab.archlinux.org/pacman/pacman/-/blob/90df85e9cf2fef38442345ea3171300399f3ca98/lib/libalpm/sync.c#L740 3. curl_multi_info_read returns NULL immediately, so curl_download_internal fails to call curl_check_finished_download since no transfer was started, meaning the .part file has not being renamed https://gitlab.archlinux.org/pacman/pacman/-/blob/90df85e9cf2fef38442345ea3171300399f3ca98/lib/libalpm/dload.c#L917 4. _alpm_filecache_find(handle, "foo.pkg.tar.zst") misses, assigning pkgname NULL https://gitlab.archlinux.org/pacman/pacman/-/blob/90df85e9cf2fef38442345ea3171300399f3ca98/lib/libalpm/sync.c#L996 5. _alpm_pkg_validate_internal errors on this NULL pointer which ripples up, cancelling the transaction https://gitlab.archlinux.org/pacman/pacman/-/blob/90df85e9cf2fef38442345ea3171300399f3ca98/lib/libalpm/be_package.c#L284 As an aside, the error messages aren't too helpful for the average user. In the case that the package is the only one being installed: :: Proceed with installation? [Y/n] :: Retrieving packages... (1/1) checking keys in keyring (1/1) checking package integrity error: failed to commit transaction (wrong or NULL argument passed) Errors occurred, no packages were upgraded. In the case that more than one package (not sure about this assertion, it might be dependent on package ordering too): :: Proceed with installation? [Y/n] :: Retrieving packages... (3/3) checking keys in keyring (3/3) checking package integrity error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded. Neither of these messages are much help to the average user unfortunately :) |
This task depends upon
Comment by
David Phillips (phillid) -
Wednesday, 16 February 2022, 04:53 GMT
Comment by Allan McRae (Allan) -
Wednesday, 16 February 2022, 04:57 GMT
Re-attaching pacman-bug.sh since it looks like this was dropped
from my initial submission.
This bug is filling me with dejavu! I'm sure this was fixed, but
perhaps we regressed again when moving to parallel downloads...