[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] WGET bug with --timestamping

From: Micah Cowan
Subject: Re: [Bug-wget] WGET bug with --timestamping
Date: Sat, 06 Dec 2008 11:47:36 -0800
User-agent: Thunderbird (X11/20081125)

Hash: SHA1

Jay Pellam wrote:
> Confirmed in 1.10.1, the latest binary Windows build I've found.
> Was also in 1.8.2, the previous Win32 version I have.
> Contrary to what the help says (--timestamping: don't re-retrieve files 
> unless newer than local), WGET re-retrieves the file and overwrites a NEWER 
> file if the sizes are different.
>       Resolving img47.imageshack.us...
>       Connecting to img47.imageshack.us||:80... connected.
>       HTTP request sent, awaiting response... 200 OK
>       Length: 60,988 (60K) [image/jpeg]
>       The sizes do not match (local 45025) -- retrieving.

By the definition of mirroring (which is the perspective Wget takes on
these things), the file on the local filesystem can't be "newer" than
the remote file: the server is assumed to be the authoritative source of
the file. If the sizes differ, the files differ, so therefore it's
necessary to pull down the authoritative version: the server's.

> To me this seems clearly wrong.  There is no question that its wrong when the 
> performance is compared to the documentation.  I could understand why you 
> might not want to change this behavior absolutely but if not a new switch 
> should be provided, eg, --ignoresize.

The current documentation makes it clearer:

>    If the local file does not exist, or the sizes of the files do not
> match, Wget will download the remote file no matter what the time-stamps
> say.

The following phrase is a bit off, especially considering what I just
wrote again:

> ...Wget will check
> whether a local file of the same name exists.  If it does, and the
> remote file is older, Wget will not download it.

Should be "remote file is not newer", as older would be an unusual case
that falls outside the expected use of this option.

> For the documented purpose (mirroring) it seems like it could be disasterous 
> in many situations.

I can't fathom how. By definition, a mirror defers authority to the
origin server.

What is the situation in your case that actually results in a newer file
on the local end than the remote?

I could probably accept a patch to implement an --ignore-sizes; it won't
go in for 1.12 though.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]