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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> Jabber:[email protected] GnuPG 1024D/728E 6696 F43D D622 78F1 F481 45C0 2147 69AB DD54 software engineer:open standards/access/knowledge:enthgnusiast
