search

rpm-software-management / librepo

A library providing C and Python (libcURL like) API for downloading packages and linux repository metadata in rpm-md format
http://rpm-software-management.github.io/librepo/
GNU Lesser General Public License v2.1
74 stars 91 forks source link

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

Open hedayat opened 9 months ago

hedayat commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 :thinking:

jan-kolarik commented 9 months ago

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 commented 9 months ago

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. :relaxed:

jan-kolarik commented 7 months ago

Another use case that should be covered when fixing this: https://github.com/rpm-software-management/dnf/issues/2051#issuecomment-1946148621.