Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 223917 - wget broken, thinks file is present locally even if its not
Summary: wget broken, thinks file is present locally even if its not
Alias: None
Product: Fedora
Classification: Fedora
Component: wget
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-23 01:23 UTC by Behdad Esfahbod
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-12 13:09:55 UTC

Attachments (Terms of Use)

Description Behdad Esfahbod 2007-01-23 01:23:51 UTC
Description of problem:

Since the last update (Jan 10 07, 1.10.2-3.3), wget is acting very weird, mostly
thinking that the file I ask it to download exists locally (while it doesn't)
and falls back to comparing its timestamp to the remote file and then either
refusing to download completely, or leaving me with a zero-sized file...

I don't have fully reproducable instructions for this.  In one instance it only
happened if called from a shell script, but worked ok from the command line.  In
another instance, passing --output-document caused it.  Removing that argument
fixed it.  Something like an uninitialized memory I'd say.

This one happens right now:

$ wget
Connecting to||:80... connected.
HTTP request sent, awaiting response... 304 Not Modified
20:22:37 ERROR 304: Not Modified.

$ ls -l vte-0.15.2.tar.bz2
ls: vte-0.15.2.tar.bz2: No such file or directory

Comment 1 Karsten Hopp 2007-01-23 13:33:08 UTC
I cannot reproduce this on my machine (Rawhide with wget-1.10.2-3.3).
Are you really using the FC-5 version on FC6 or is just 'Version' in this
bugzilla set wrong ?

If you're running FC-5 with latest updates I'll probably need to install a
machine with that and test it.

Comment 2 Behdad Esfahbod 2007-01-23 19:16:58 UTC
Sorry.  I'm on FC5.

I cannot reproduce it using the command in my original report anymore.  As I
said, it's not 100% reproducable.

In all instances that it occured, I was trying to download a file with very
recent modification time (just uploaded, etc).  So I think it has something to
do with the time difference between the remove server and my machine.  Something
like: if you try to download a file with modification time after the client's
time, or something like that...

Comment 3 Karsten Hopp 2007-02-12 13:09:55 UTC
I've tried several combinations of modification times here and couldn't
reproduce it. Please reopen if you can get a step-by step description how to
force this error.

Comment 4 Behdad Esfahbod 2007-02-13 18:39:14 UTC
I've upgraded to FC6 in the mean while and it works fine so far.

Comment 5 Behdad Esfahbod 2007-03-13 01:27:52 UTC
Humm, experienced this again.  I released a new vte tarball and uploaded it to
gnome FTP servers about two hours ago.  Now trying to download it, the first
time I got:

[behdad@behdad devel]$ wget
2001:6b0:e:2018::158, ...
Connecting to||:80... connected.
HTTP request sent, awaiting response... 304 Not Modified
21:22:36 ERROR 304: Not Modified.

Trying again chose another server and succeeded:

[behdad@behdad devel]$ wget
2001:6b0:e:2018::159, ...
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1095254 (1.0M) [application/x-bzip2]
Remote file is newer, retrieving.

Reusing existing connection to
HTTP request sent, awaiting response... 200 OK
Length: 1095254 (1.0M) [application/x-bzip2]
Saving to: `vte-0.16.0.tar.bz2'

1,095,254    112K/s   in 7.9s   

21:24:13 (135 KB/s) - `vte-0.16.0.tar.bz2' saved [1095254/1095254]

Removing the file and trying again, I got it download from the first server too.
 So, not sure what's wrong here, the server or wget.

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