Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

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
Task Type Bug Report
Category Backend/Core
Status Assigned
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version git
Due in Version 6.1.0
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

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
Re-attaching pacman-bug.sh since it looks like this was dropped from my initial submission.
Comment by Allan McRae (Allan) - Wednesday, 16 February 2022, 04:57 GMT
This bug is filling me with dejavu! I'm sure this was fixed, but perhaps we regressed again when moving to parallel downloads...

Loading...