DNF5 always removes partially downloaded files when interrupted, so you cannot resume downloading them

[hedayat]

I tried both running dnf5 install ... and dnf5 download ... in Fedora 39, and interrupting them in the middle of downloading a large package. Upon interruption, the partially downloaded file is removed. Hence, you cannot resume downloading the package. I tried also adding keepcache option, but it has no effect.

Effectively, DNF5 doesn't have support for resume functionality right now.

[jan-kolarik]

Hi, I've been testing the described issue on my local machine, and it appears to be related to the librepo component handling package downloads. Therefore, I've transferred the problem there.

The issue lies in how librepo processes interruptions. When a SIGTERM is sent to the DNF process, the partially downloaded file is retained and resumed upon the next download attempt. However, when a SIGINT (CTRL+C) is sent, the file is discarded, resulting in the following error:

>>> Not finished - interrupted by error: Interrupted by signalFailed to download packages
 Librepo error: Interrupted by a SIGINT signal

Upon comparing this behavior to DNF4, I observed that it behaves similarly, just with different output.

[jan-kolarik]

I wasn't investigating deeply why the file is removed when SIGINT is used, but it seems that the issue may be related to this section: https://github.com/rpm-software-management/librepo/blob/1.17.0/librepo/downloader.c#L2817.

[hedayat]

Upon comparing this behavior to DNF4, I observed that it behaves similarly, just with different output.

TBH, I hope DNF5 doesn't try to replicate bad behaviors from DNF4 :P Although, I agree it depends on how you interpret Ctrl+C: Cancel vs Interrupt.

But, if the current behavior is retains, so we should either terminate DNF5 by other means or hope it'll terminate by itself upon timeout/...?

And, does it mean that if DNF has downloaded a number of packages and you press Ctrl+C, it'll remove all of them? Not sure that's what a user expects 🤔

[jan-kolarik]

TBH, I hope DNF5 doesn't try to replicate bad behaviors from DNF4 :P Although, I agree it depends on how you interpret Ctrl+C: Cancel vs Interrupt.

But, if the current behavior is retains, so we should either terminate DNF5 by other means or hope it'll terminate by itself upon timeout/...?

I've just done preliminary analysis of the issue, but I don't think that the current behavior is good. It should be fixed.

And, does it mean that if DNF has downloaded a number of packages and you press Ctrl+C, it'll remove all of them? Not sure that's what a user expects 🤔

No, pressing Ctrl+C while downloading packages will only remove the package currently being downloaded, but not those that have already finished downloading.

[hedayat]

I've just done preliminary analysis of the issue, but I don't think that the current behavior is good. It should be fixed.

Sure, thanks :)

No, pressing Ctrl+C while downloading packages will only remove the package currently being downloaded, but not those that have already finished downloading.

Good. Because I thought maybe the decision was made that when you press Ctrl+C, you want to cancel the operation. In that case, other package should have been removed. Since they are not removed, I can safely assume that retaining partial file is also OK. ☺️

[jan-kolarik]

Another use case that should be covered when fixing this: rpm-software-management/dnf#2051 (comment).

[radiumatic]

I thought this issue was fixed, but apparently not.
Has there been any progress?
dnf5 successfully switches between mirrors when a timeout occurs, but when "Failure when receiving data from the peer for X" happens, it just wipes the file.