Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#34973 - Disable file resuming during pacman sync
Attached to Project:
Pacman
Opened by Ryan Rapini (betarepeating) - Friday, 26 April 2013, 14:19 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 10 July 2013, 14:20 GMT
Opened by Ryan Rapini (betarepeating) - Friday, 26 April 2013, 14:19 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 10 July 2013, 14:20 GMT
|
DetailsSummary and Info:
Behind my corporate firewall, HTTP file resumes are blocked for some reason. This means that if a file ever fails to download, I get this: error: failed retrieving file 'xxx.pkg.tar.xz' from x1.com: HTTP server doesn't seem to support byte ranges. Cannot resume. error: failed retrieving file 'xxx.pkg.tar.xz' from x2.com: HTTP server doesn't seem to support byte ranges. Cannot resume. error: failed retrieving file 'xxx.pkg.tar.xz' from x3.com: HTTP server doesn't seem to support byte ranges. Cannot resume. ... And so on until it has exhausted all of the mirrors in my mirrorlist. From here, the only way to recover is to run pacman -Scc and nuke my entire file cache, at which point I can reattempt the install and hope it will work. I would like to request a config file flag or a sync option to disallow resuming of files. Steps to Reproduce: 1.) Prep your resume 2.) Go get hired by a big company with a horrible network architecture 3.) Attempt to pacman -Syu 4.) Eventually, the proxy will hang during a file download and it will timeout. When this happens, you will immediately be flooded with errors as all of your mirrors fail to resume the download one by one. 5.) pacman -Scc 6.) pacman -S offendingpackage 7.) It fails again 8.) Weep 9.) Goto 5. |
This task depends upon
Closed by Dave Reisner (falconindy)
Wednesday, 10 July 2013, 14:20 GMT
Reason for closing: Won't implement
Additional comments about closing: Broken servers should be dealt with at the server level. It's 2013, and accepting range requests isn't an exotic thing to expect.
Wednesday, 10 July 2013, 14:20 GMT
Reason for closing: Won't implement
Additional comments about closing: Broken servers should be dealt with at the server level. It's 2013, and accepting range requests isn't an exotic thing to expect.
Well that's a load of crap -- you can simply delete the .part files in your cache.
Well. I never even thought about doing that... I feel pretty stupid.
While this certainly makes things easier, it still would be nice to have a 'set-and-forget' option in pacman.conf to disallow file resuming in network environments that don't support it.
I was a bit unsure whether to add line 94 of lib/libalpm/sync.c because you pass the handle in that has the option anyway, but I decided to add it because dload.c doesn't seem to use the options in handles much.
The only testing I've done is manual (as well as run the pre-existing tests).
So true!
@falconindy:
I understand and accept this! Would be insane to patch stuff like that with workarounds. I've delete the part files!