Bug 231572 - wget with -nc aborts when it finds the first file that already exists
wget with -nc aborts when it finds the first file that already exists
Product: Fedora
Classification: Fedora
Component: wget (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Karsten Hopp
Depends On:
  Show dependency treegraph
Reported: 2007-03-08 21:41 EST by Polo Talnir
Modified: 2008-02-07 06:20 EST (History)
1 user (show)

See Also:
Fixed In Version: F-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-07 06:20:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Polo Talnir 2007-03-08 21:41:11 EST
Description of problem:
wget with -nc aborts when it finds the first file that already exists.
Start a wget download and interrupt it (because it is too long, or
because the machine crashed or because the soup is getting cold).
Then try to resume the download using the -nc parameter: wget aborts
as soon as it finds an already existing file. The intended semantics
is that wget will skip these files and continue downloading those that
were not downloaded in the first run. Indeed, anything else makes the
program less than useful as it precluded decent resumption of a long

I compiled the official sources wget-1.10.2.tar.gz from
http://ftp.gnu.org/gnu/wget/ and it works fine, just as expected,
continuing downloading from the point where it was stopped, skipping
existing files.

Version-Release number of selected component (if applicable):
1.10.2-8.fc6.1. I used this build on FC5 in order to check whether
the wrong behaviour that I found in the build (Fedora Core 5 update)
1.10.2-3.3.fc5 was fixed, but it was not. Both versions are wrong.
(surprising the the fc6 RPM installed without complaints in FC5).

How reproducible:

Steps to Reproduce:
1. enter the following command:
 $ wget -erobots=off -o wget.log -nH -r 
(one line) and let it run for 2 minutes.
2. ^C to stop it.

3. enter the following command, including -nc -c (to continue download
   of a partially downloaded file, if any, and new files not-yet downloaded:
   wget -erobots=off -nH -c -r -nc
   (in one line).

Actual results:
  $ wget -erobots=off -nH -c -r -nc
--18:29:27--  http://pure-data.cvs.sourceforge.net/pure-data/doc/tutorials/
Resolving pure-data.cvs.sourceforge.net...
Connecting to pure-data.cvs.sourceforge.net||:80... connected.
HTTP request sent, awaiting response... 200 OK
File `pure-data/doc/tutorials/index.html' already there; not retrieving.



====> notice the "Aborted" line. 

Expected results:

File `pure-data/doc/tutorials/index.html' already there; not retrieving.

Warning: wildcards not supported in HTTP.
File `*docroot*/styles.css' already there; not retrieving.

File `pure-data/index.html' already there; not retrieving.

File `pure-data/doc/index.html' already there; not retrieving.

.... etc ...

This is the output from my locally compiled wget from the GNU sources.

Additional info:

Comment 1 Luciano Rocha 2007-05-11 06:46:27 EDT
I can reproduce this. I have a core, if anyone is interested.

The abort happens at http.c, line 2599.

I don't know how it gets there, as hstat.res == -1 and thus we shouldn't be
inside the if @ 2559 (and then, inside the if @ 2561). Either it's a compiler
bug or the debuginfo package is wrong.

hstat = {len = 0, contlen = -1, restval = 0, res = -1, rderrmsg = 0x0, 
  newloc = 0x0, remote_time = 0x0, error = 0x0, statcode = 0, rd_size = 0, 
  dltime = 0, referer = 0x0, 
  local_file = 0x9bce378 "www.redhat.com/robots.txt", 
  timestamp_checked = false, orig_file_name = 0x0, orig_file_size = 0, 
  orig_file_tstamp = 0}

rpm -q wget wget-debuginfo --qf '%{name}-%{version}-%{release}.%{arch}\n':

Comment 2 Ralph Loader 2008-02-05 14:34:31 EST
Should this bug be closed?  I can no longer reproduce it.
Comment 3 Karsten Hopp 2008-02-07 06:20:43 EST
Closing as FC-6 isn't supported anymore and more recent releases don't seem to
have this bug.

Note You need to log in before you can comment on or make changes to this bug.