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 http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.15/vte-0.15.2.tar.bz2 --20:22:36-- http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.15/vte-0.15.2.tar.bz2 Resolving ftp.acc.umu.se... 130.239.18.159, 130.239.18.158 Connecting to ftp.acc.umu.se|130.239.18.159|: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
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.
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...
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.
I've upgraded to FC6 in the mean while and it works fine so far.
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 http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.16/vte-0.16.0.tar.bz2 --21:22:35-- http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.16/vte-0.16.0.tar.bz2 Resolving ftp.acc.umu.se... 130.239.18.159, 130.239.18.158, 2001:6b0:e:2018::158, ... Connecting to ftp.acc.umu.se|130.239.18.159|: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 http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.16/vte-0.16.0.tar.bz2--21:24:04-- http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.16/vte-0.16.0.tar.bz2 Resolving ftp.acc.umu.se... 130.239.18.158, 130.239.18.159, 2001:6b0:e:2018::159, ... Connecting to ftp.acc.umu.se|130.239.18.158|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1095254 (1.0M) [application/x-bzip2] Remote file is newer, retrieving. --21:24:05-- http://ftp.acc.umu.se/pub/GNOME/sources/vte/0.16/vte-0.16.0.tar.bz2 Reusing existing connection to ftp.acc.umu.se:80. HTTP request sent, awaiting response... 200 OK Length: 1095254 (1.0M) [application/x-bzip2] Saving to: `vte-0.16.0.tar.bz2' 100%[==========================================================================>] 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.