FS#23803 - Truncated database files and "Requested Range Not Satisfiable"

Attached to Project: Pacman
Opened by Xyne (Xyne) - Sunday, 17 April 2011, 03:58 GMT
Last edited by Dave Reisner (falconindy) - Monday, 22 August 2011, 16:58 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version 3.5.1
Due in Version 4.0.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This appears to be a regression: https://bugs.archlinux.org/task/15657

Updating the database fails with:
error: core.db appears to be truncated: 38389/38390 bytes 0.0K 0.0K/s 00:00:00
error: failed retrieving file 'core.db' from example.com : Requested Range Not Satisfiable

This first appeared tonight with mirrors.kernel.org as my main mirror. The second mirror does not matter. The only way to resolve the error is to remove the *.part files in the sync database, then change the main mirror.

The resulting .part files were all the same size as the target database each time.


Steps to reproduce:
cd /var/lib/pacman/sync
mv core.db core.db.part
pacman -Sy
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 22 August 2011, 16:58 GMT
Reason for closing:  Fixed
Comment by Allan McRae (Allan) - Sunday, 17 April 2011, 04:25 GMT
I think this is related to  FS#20022 . The only time we ever see issues like these is with people using mirrors.kernel.org. There have been quite a few similar reports with people and the community db using the kernel.org mirrors lately.
Comment by Xyne (Xyne) - Sunday, 17 April 2011, 14:27 GMT
The issue might only appear right now when using mirrors.kernel.org, but it is definitely a pacman issue. Pacman makes incorrect assumptions about database files, namely that all mirrors in the mirrorlist will have the same database file (i.e. that they are all in sync), that the database file has not been updated on the server since the .part file was created, and that the .part file is always incomplete.

This particular case seems to be caused by the last assumption. Pacman should detect range errors when possible and remove the .part file. If it cannot determine the status code (e.g. when using XferCommand) then it should simply remove the .part file if the download fails.

As for the first two assumptions, I think that in the absence of versioned databases, it should only try to continue a download from the same mirror, and only within a given interval (e.g. .part it not older than x minutes).

Comment by Dave Reisner (falconindy) - Monday, 22 August 2011, 16:58 GMT
Fixed in 204bbc47149c948b68

Loading...