[Top][All Lists]

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

Re: [Bug-wget] wget -N timestamp sometimes off by one second

From: Daniel A. Nagy
Subject: Re: [Bug-wget] wget -N timestamp sometimes off by one second
Date: Fri, 06 Apr 2012 01:59:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20120313 Thunderbird/3.1.20

On 04/06/2012 01:01 AM, Ángel González wrote:
> On 05/04/12 21:51, Daniel A. Nagy wrote:
>> Version: 1.13.4
>> Operating System: OpenWrt 10.03.1
>> Kernel: Linux
>> Filesystem: vfat
>> What happens is that wget -N writes a filestamp that is one second
>> earlier than the Last-modified HTTP header and therefore when invoked
>> again, downloads the same file again even though it should not. So, the
>> timestamp it uses for comparison is right, but the one that ends up
>> written on the filesystem is wrong.
>> It's not even consistent, with most files it works okay, but for some,
>> it does not work. So far, I did not manage to find any pattern in those
>> files that end up mis-timestamped.
> vfat has a two-second precision for modified time. If the file was last
> modified
> in an odd second (if I remember right), the filesystem will store it in
> the even
> one, thus always showing as modified. Many tools get fooled with that, such
> as make.

Thank you! That makes a lot of sense and indeed seems to be the root of
my problem.

Now, I can (and will) obviously work around it (e.g. by using a
different fs), but maybe this would be a nice feature in wget: a switch
that turns off least significant bit comparison (that is masks both
before comparing) in timestamps when deciding whether or not to download.

So, consider this a feature suggestion. I might even implement it myself.



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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