FS#39257 - Well-timed Ctrl-C during download rename makes update fail

Attached to Project: Pacman
Opened by Dan McGee (toofishes) - Sunday, 09 March 2014, 21:47 GMT
Last edited by Allan McRae (Allan) - Friday, 13 December 2019, 14:10 GMT
Task Type Bug Report
Category Backend/Core
Status Closed
Assigned To Allan McRae (Allan)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.2
Due in Version 6.0.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

If you manage to Ctrl-C between when 1) libalpm downloads the file and 2) it calls rename, you end up in a situation pacman doesn't know how to get itself out of. Yes, I somehow managed to do this.

To reproduce without needing to win the lottery, simply rename a current sync package file in your cache and tack '.part' on the end. You'll then see that the following happens:

debug: found cached pkg: /var/cache/pacman/pkg/systemd-sysvcompat-210-2-x86_64.pkg.tar.xz.part
debug: using (package - .part) size
debug: setting download size 0 for pkg systemd-sysvcompat
debug: returning error 31 from alpm_db_get_pkg : could not find or read package

Because the download size is set to 0, libalpm gets confused- it thinks the file is fully downloaded (causing it not to be added to the download loop), but the only place things get renamed is inside the downloader.

I tried a quick hack at this, but there isn't an easy solution that I could figure out. I'd suggest maybe doing the rename operation outside of the "is this fully downloaded" check, perhaps? You know best though.

https://paste.xinu.at/vm3/
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 13 December 2019, 14:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  git commit e6a6d307
Comment by Dan McGee (toofishes) - Sunday, 09 March 2014, 21:48 GMT
I don't think it is of much use, but I attached my start of a hack before I realized this was a bigger problem than I expected it to be.
Comment by Eli Schwartz (eschwartz) - Wednesday, 12 December 2018, 06:04 GMT
Actually this seems to just be  FS#35789 .

Loading...