Re: [Bug-wget] [Patch] Regression: write error on wget -c for already fully retrieved file

[Torsten Scheck]

Hi Giuseppe,

thank you very much for your quick response.

Giuseppe Scrivano wrote on 13.11.2012 23:59:
> I think the proper patch should be this:
> 
> diff --git a/src/retr.c b/src/retr.c
[...]
> -          if (write_res != 0)
> +          if (write_res < 0)

Your change prevents the error message, but the file seems to be fully
retrieved rather than continued (see below).

For my yocto check it doesn't matter, of course. Nevertheless, I would
expect the message "The file is already fully retrieved; nothing to do.".

Cheers,
Torsten



$ src/wget -P ~ 'https://eula-downloads.yoctoproject.org/index.php'
...
$ src/wget -c -P ~ 'https://eula-downloads.yoctoproject.org/index.php'
--2012-11-14 22:49:23--  https://eula-downloads.yoctoproject.org/index.php
Resolving eula-downloads.yoctoproject.org
(eula-downloads.yoctoproject.org)... 140.211.169.56
Connecting to eula-downloads.yoctoproject.org
(eula-downloads.yoctoproject.org)|140.211.169.56|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/home/t/index.php’

    [   <=>                                  ] 105,711      227KB/s   in
0.5s

2012-11-14 22:49:25 (227 KB/s) - ‘/home/t/index.php’ saved [105711]




> Torsten Scheck <address@hidden> writes:
> 
>> Dear wget community,
>>
>> the Yocto Project's sanity checks for connectivity fail on Debian unstable,
>> as the current wget -c reports a write error for an already fully retrieved
>> file. (Yocto is an OpenEmbedded-based system builder suite.)
>>
>> This issue might depend on server behaviour, so please test with the URL
>> provided below.
>>
>> Steps to reproduce:
>>
>> 1. Download file from yocto server
>> $ wget 'https://eula-downloads.yoctoproject.org/index.php'
>> ...
>> 2012-11-13 19:23:37 (146 KB/s) - ‘index.php’ saved [105711]
>>
>> 2. Download same file from yocto server with -c
>> $ wget -c 'https://eula-downloads.yoctoproject.org/index.php'
>> ...
>> Cannot write to ‘index.php’ (Resource temporarily unavailable).
>> $ echo $?
>> 3
>>
>> Expected behaviour:
>>
>> "The file is already fully retrieved; nothing to do."
>> status code: 0
>>
>>
>> I used "git bisect" and found the following commit as culprit:
>>
>> -----------------------8<-------------------------8<----------------------
>> commit 954fead685de2cc972552ed1b294a84845cf638a
>> Author: Alan Jenkins <address@hidden>
>> Date:   Tue Jul 20 19:42:13 2010 +0200
>>
>>     Fix a failure if the server doesn't specify a content-length and -c is
>> used.
>> -----------------------8<-------------------------8<----------------------
>>
>>
>> When I undo this commit's change in the current master branch, wget works
>> as expected for my use case.
>>
>> -----------------------8<-------------------------8<----------------------
>> diff --git a/src/http.c b/src/http.c
>> index 5888474..1a4ccda 100644
>> --- a/src/http.c
>> +++ b/src/http.c
>> @@ -2690,7 +2690,7 @@ read_header:
>>
>>    if (statcode == HTTP_STATUS_RANGE_NOT_SATISFIABLE
>>        || (!opt.timestamping && hs->restval > 0 && statcode == HTTP_STATUS_OK
>> -          && contrange == 0 && contlen >= 0 && hs->restval >= contlen))
>> +          && contrange == 0 && hs->restval >= contlen))
>>      {
>>        /* If `-c' is in use and the file has been fully downloaded (or
>>           the remote file has shrunk), Wget effectively requests bytes
>> -----------------------8<-------------------------8<----------------------
>>
>>
>> But Mr. Alan Jenkins surely had a use case which he had fixed with his
>> commit. Are there any regression tests which I can run?
>>
>> I would be nice if wget were able to work for all use cases.
>> Please have a look in this issue, if you're a wget maintainer.
>>
>> Cheers,
>> Torsten Scheck
> 
> 

-- 
Torsten Scheck <address@hidden>  Jabber:address@hidden
GnuPG 1024D/728E 6696 F43D D622 78F1  F481 45C0 2147 69AB DD54
software engineer:open standards/access/knowledge:enthgnusiast