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

[Giuseppe Scrivano]

Thanks for the report.  The code you have reverted seems correct to me.

I think the proper patch should be this:

diff --git a/src/retr.c b/src/retr.c
index 6204839..5bbae80 100644
--- a/src/retr.c
+++ b/src/retr.c
@@ -376,7 +376,7 @@ fd_read_body (int fd, FILE *out, wgint toread, wgint 
startpos,
         {
           sum_read += ret;
           int write_res = write_data (out, out2, dlbuf, ret, &skip, 
&sum_written);
-          if (write_res != 0)
+          if (write_res < 0)
             {
               ret = (write_res == -3) ? -3 : -2;
               goto out;


It works here for me, can you confirm it?

Cheers,
Giuseppe



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