11 May 2010

Wget 1.12 for windows

I know it kind of old version. but I've been given up with stupid unclean yet inconsistent Teleport while trying to mirror valadoc.org. I'm planning to make chm version of the sites, but there is some gotchas with retrieval process currently (could be fixed with v-grep though).

For anyone interested  here is win32 binary wget-1.12  (545KB builtin OpenSSL 1.0)
Alternate build (see update notes below) wget.exe

Wget source is available at http://www.gnu.org/software/wget/

February 23, 2015
Updated downloads moved to main page 

October 29, 2014
wget-1.16 (with openssl 1.0.1i, pdf manual, wget.ini sample, locales and ca certificate)
Use 7zip/WinRAR to extract the archive

January 22, 2014
wget-1.15 (with openssl 1.0.1f, pdf manual, wget.ini sample, locales and ca certificate)

August 11, 2012
wget-1.14 (openssl 1.0.1c) optional files (locales, ca-bundle)

February 1, 2012
wget-1.13.4 (openssl 1.0.0g) locales ca-bundle-crt (expired 2018) [patch]
- wget should lookup wget.ini and locales relative to where wget.exe located not from current directory
- by default search for curl-ca-bundle.crt for secure protocol when ca-certificate-file not defined


December 7, 2011
wget-1.13.4 (openssl 1.0.0e) locales
- fixed gnulib stat() that return invalid filesize >2GB (patched mswindows.h)
- use wget.ini in current directory for default wgetrc
- apply apache's dirlist patch

September 6, 2011
wget-1.13.1.exe
- timestamp fix and apache dirlist patch

How to build?
Someone asked, but honestly I don't find anything intricate about building it with MinGW.. the one that hard is version 1.12.x where I need to modify some win32api's header to enable IPv6, apply some minor patch and manually "make" for the final linking. Version 1.13.x however is just simply configure and make, that's it. Of course assuming you already had all dependencies (libidn, libintl, winiconv, openssl), one caveat is libidn as user commented below, it maybe just me (i'm not sure) but I need to rebuild winiconv and later libidn to make it "see" the statically linked iconv.

March 30 2011
I made alternative build based on this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217243 to workaround those annoying apache auto-generated directory listings.
As you can see, we still can't get rid of index.html, but it's way much faster for handling hundreds of directories! enjoy! :)

May 14 2010
It seems my previous mingw built didn't support IPv6 :D
That's really strange.. AFAIK ws2tcpip.h does support IPv6. I decide to fool configure to enable it. And I've done it. The new binary now support IPv6 and IRI. Same link as above.

74 comments:

  1. Can you compile release 1.13 of wget?

    ReplyDelete
  2. Dude, don't use url as name! otherwise your comment went to spam..

    Here you go (untested)
    http://dl.dropbox.com/u/2554170/wget-1.13.1.exe
    with apache dirlist patch

    Enjoy

    ReplyDelete
  3. Thank you very much TumaGonx Zakkum. I've been trying wget 1.12 (for Windows) from lots of webs, and all of these (included yours) have the same problem: when I add an input file with a full path like this: -i d:\mydir\links.txt I get the error: No URLs found.
    But your 1.13.1 version works perfectly. THANKS.

    Inframan

    ReplyDelete
  4. I've just discovered that the 1.13.1 version has a minor problem: it doesn't retrive the original files' time stamps. It was the default behaviour of my former 1.11.4.

    Inframan

    ReplyDelete
  5. your first problems, you should use relative path for your input list not absolute, but I always prefer wgetrc way (in this case use set wgetrc=[absolute path to wgetrc]

    for timestamp, it works just fine again I recommend use thw wgetrc way man, it goes like this:

    background = on
    input = config/down.txt
    logfile = log.txt
    convert_links = on
    no_parent = on
    noclobber = off
    continue = on
    recursive = on
    adjust_extension = on
    verbose = on
    quota = inf
    tries = 30
    reclevel = inf
    passive_ftp = on
    waitretry = 10
    restrict-file-names = windows
    timestamping = on
    wait = 1
    dirstruct = on
    follow_ftp = on
    limit_rate = 8k
    dir_prefix = D:\Leech\downloads
    #http_proxy = http://127.0.0.1:8080

    tumagonx

    ReplyDelete
  6. then check your logs to see why stamping doesn't work, I believe it was server-side issue

    ReplyDelete
  7. I used the wgetrc with your options (especially timestamping = on), but it keeps failing. Every file is saved with the current time, not the original. And yes, on some ocassions it's a server-side issue, but not always. The only error I saw in my log was:
    futimens(D:/downloaded file in my hdd): Function not implemented

    About the full path, sometimes I have the file in a USB drive, so it's needed to write the full path (including the letter for drive) to make it works.

    Thanks for your quick answer and help

    Inframan

    ReplyDelete
  8. hmm, those futimens error usually special file like robot.txt
    my usual error is "Last-modified header missing" for all autogenerated files.

    Well, glad 1.13.1 fix that input list path... My way is to put wget.exe, wgetrc, wget.bat and the listfile in a folder so even in flashdisk that doesn't really matter.

    ReplyDelete
  9. after see the source, futimens is newly introduced in 1.13 but seems implemented for linux only and you're right it handle time-modification of file

    ReplyDelete
  10. I revert timestamping to previous version (before using futimens), it works now. And it seems has no side effect as it only used in utils.c. Thanks alot for the report man.
    enjoy

    ReplyDelete
  11. Now that it's fixed the timestamping, I can use this version on a daily basis instead of the dated 1.11.4 from http://users.ugent.be/~bpuype/wget/. If something's going wrong, I'll make you know. Thanks to you for compiling, fixing and sharing with the community.

    Inframan

    ReplyDelete
  12. When I run it on Windows 7 I get an error about libidn:
    C:\bin>wget-1.13.1.exe -6 www.savvis.com
    --2011-09-05 21:32:17-- http://www.savvis.com/
    libidn: warning: libiconv not installed, cannot convert data to UTF-8
    Resolving www.savvis.com (www.savvis.com)... 2001:460:100:1000::37
    libidn: warning: libiconv not installed, cannot convert data to UTF-8
    Connecting to www.savvis.com (www.savvis.com)|2001:460:100:1000::37|:80... failed: Bad file descriptor.

    C:\bin>

    What's the issue?

    ReplyDelete
  13. The previous libidn apparently not linked to correct libiconv (I use winiconv). Updated, thanks for your report Frank

    ReplyDelete
  14. Could you please build wget 1.13.4?

    ReplyDelete
  15. http://dl.dropbox.com/u/2554170/wget-1.13.4/wget.exe (untested)

    ReplyDelete
  16. Can you give us a guide for compile wget 1.13.4?I have tried, but failed, the wget which I compiled cannot support openssl, and need libidn-11.dll

    ReplyDelete
  17. Thanks!
    wget executable without any external dependencies and DLL is so cool and convenient.

    ReplyDelete
  18. Hi,
    perfect job! Could you try build 64bit version too? Thanks a lot

    ReplyDelete
  19. Hello. Big file download error.
    1.11.4 works fine
    Thank You

    M:\DELL>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    --2011-12-02 15:07:41-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving ftp.dell.com (ftp.dell.com)... 143.166.170.10, 143.166.170.10
    Connecting to ftp.dell.com (ftp.dell.com)|143.166.170.10|:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /sysman ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> PASV ... done. ==> REST -2030076516 ...
    REST failed, starting from scratch.

    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G) (unauthoritative)

    0% [ ] 0 --.-K/s in 0,2s

    sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.

    ReplyDelete
  20. Sorry can't reproduce that, works for me:

    E:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c ftp://ftp.dell.com/sysm
    an/sm_6.5.0-15_A00.2.iso
    --2011-12-02 19:15:55-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving ftp.dell.com (ftp.dell.com)... 143.166.170.10
    Connecting to ftp.dell.com (ftp.dell.com)|143.166.170.10|:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /sysman ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> PASV ... done. ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2.7G) (unauthoritative)

    0% [ ] 62,560 2.56K/s eta 11d 18h

    ReplyDelete
  21. File was downloaded for about 2.1 GB before error occures

    ReplyDelete
  22. Resuming after replacing 1.13.4 with 1.11.4

    M:\DELL>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
    syswgetrc = c:/progra~1/wget/etc/wgetrc
    --2011-12-02 15:09:09-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving ftp.dell.com... 143.166.170.10, 143.166.170.10
    Connecting to ftp.dell.com|143.166.170.10|:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD /sysman ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> PASV ... done. ==> REST 2264890780 ... done.
    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G), 623880804 (595M) remaining

    100%[++++++++++++++++++++++++++++++++++++++++++++============>] 2 888 771 584 308K/s in 36m 14s

    2011-12-02 15:45:27 (280 KB/s) - `sm_6.5.0-15_A00.2.iso' saved [2888771584]

    ReplyDelete
  23. Your first error definitely different from your last. Please don't hide the real error?

    And 2.1 Gb is pass the "large file" barrier already. So I don't have to prove it on my slow 128kpbs connection here

    ReplyDelete
  24. I got an idea to simulate this, I wrote dummy file about 2.84gb and hook it to Scientific Linux ISO download. No problemo

    E:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c ftp://ftp1.scientificli
    nux.org/linux/scientific/6.1/x86_64/iso/SL-61-x86_64-2011-11-09-Everything-DVD1.
    iso
    --2011-12-02 23:00:06-- ftp://ftp1.scientificlinux.org/linux/scientific/6.1/x86
    _64/iso/SL-61-x86_64-2011-11-09-Everything-DVD1.iso
    => `SL-61-x86_64-2011-11-09-Everything-DVD1.iso'
    Resolving ftp1.scientificlinux.org (ftp1.scientificlinux.org)... 131.225.110.41
    Connecting to ftp1.scientificlinux.org (ftp1.scientificlinux.org)|131.225.110.41
    |:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /linux/scientific/6.1/x86_64/iso ... done.
    ==> SIZE SL-61-x86_64-2011-11-09-Everything-DVD1.iso ... 4492019712
    ==> PASV ... done. ==> REST -1237838128 ... done.
    ==> RETR SL-61-x86_64-2011-11-09-Everything-DVD1.iso ... done.
    Length: 4492019712 (4.2G) (unauthoritative)

    -27%[ ] -1,237,711,648 3.78K/s eta 22d 22h

    ReplyDelete
  25. Hello.
    My way to reproduce error.
    File was truncated at point 2264890780 bytes, point, where download was interrupted when downloading from ftp.dell.com.


    Trying to continue download from dell

    M:\temp>wget -c ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    --2011-12-05 08:44:17-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving ftp.dell.com (ftp.dell.com)... 143.166.11.10, 143.166.11.10
    Connecting to ftp.dell.com (ftp.dell.com)|143.166.11.10|:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /sysman ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> PASV ... done. ==> REST -2030076516 ...
    REST failed, starting from scratch.

    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G) (unauthoritative)

    0K 0% 0,00 =0,2s

    sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.

    now trying to download from local ftp site

    M:\temp>wget -c ftp://username:password@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    --2011-12-05 08:44:42-- ftp://username:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving localhost (localhost)... ::1, 127.0.0.1
    Connecting to localhost (localhost)|::1|:21... connected.
    Logging in as dstrr ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> EPSV ... done. ==> REST -2030076516 ...
    REST failed, starting from scratch.

    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G) (unauthoritative)

    0K 0% 0,00 =0,03s

    sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.

    content of working directory

    Directory of M:\temp

    05.12.2011 08:43 2 264 890 780 sm_6.5.0-15_A00.2.iso
    1 File(s) 2 264 890 780 bytes
    2 Dir(s) 582 830 100 480 bytes free



    Download of complete file without break and continue works well. May be point of REST calculates incorrectly? wget 1.11.4 makes REST without negative sign ant at different point.

    now i replaced wget.exe with 1.11.4

    M:\temp>wget -c ftp://username:password@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
    syswgetrc = c:/progra~1/wget/etc/wgetrc
    wgetrc_file_name = c:\Windows\wgetrc
    --2011-12-05 09:04:49-- ftp://username:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving localhost... 127.0.0.1, ::1
    Connecting to localhost|127.0.0.1|:21... connected.
    Logging in as dstrr ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD /mdrive/dell ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> PASV ... done. ==> REST 2264890780 ... done.
    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G), 623880804 (595M) remaining

    100%[++++++++++++++++++++++++++++++++++++++++++++============>] 2 888 771 584 29,9M/s in 14s

    2011-12-05 09:05:03 (43,6 MB/s) - `sm_6.5.0-15_A00.2.iso' saved [2888771584]

    Thank You.

    ReplyDelete
  26. Hello.
    Chronologically:
    1. wget 1.13.4 started download from dell and download was broken at point 2264890780. i maked wget -c and result was shown in the first post. i tried for a 3-5 times.
    2. wget.exe 1.13.4 was replaced with 1.11.4 and issued the same command - download was resumed and completed successfully. This shown in the second post.

    I can reproduce this behavior. i have complete file, and make partial copy with end at point 2264890780 and resuming download. i'm using dell ftp and local ftp, behavior the same, error is in place.

    Thank You.
    A hour ago i made big post with screenshots, but it disappeared.

    ReplyDelete
  27. can you display what's the invalid argument? by reading the logfile like when I ask inframan in early posts

    ReplyDelete
  28. the REST is negative but so does the progress percentage. See my comment before

    ReplyDelete
  29. E:\Dropbox\OSSPack\My Dropbox\Public\wget-1.13.4>wget -c -d ftp://ftp.dell.com/s
    ysman/sm_6.5.0-15_A00.2.iso
    DEBUG output created by Wget 1.13.4 on mingw32.

    URI encoding = `ASCII'
    --2011-12-05 14:55:25-- ftp://ftp.dell.com/sysman/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving ftp.dell.com (ftp.dell.com)... seconds 0.00, 143.166.11.10
    Caching ftp.dell.com => 143.166.11.10
    Connecting to ftp.dell.com (ftp.dell.com)|143.166.11.10|:21... seconds 0.00, con
    nected.
    Created socket 3.
    Releasing 0x00ab6d60 (new refcount 1).
    Logging in as anonymous ... 220 Microsoft FTP Service

    --> USER anonymous

    331 Anonymous access allowed, send identity (e-mail name) as password.

    --> PASS -wget@

    230-Welcome to the Dell FTP site. A service of Dell Inc., Round Rock, Texas.
    For information about DELL, call +1 800 999 3355 All transfers are logged wi
    th
    your host name and email address. If you don't like this policy please disco
    nnect now.
    Please be advised that use constitutes consent to monitoring (Elec Comm Priv
    Act,
    18 USC 2701-2711). Please see the file readme.txt for disclaimers pertaining
    to this
    service. If your FTP client crashes or hangs shortly after login, try using
    a dash
    (-) as the first character of your password. This will turn off the informat
    ional
    messages which may be confusing your ftp client.
    ********IN CASE OF PROBLEMS*************************
    ** File Content: send EMAIL to dellbbs@dell.com **
    ** FTP Server: send EMAIL to hostmaster@dell.com **
    ** WWW Server: send EMAIL to webmaster@dell.com **
    ****************************************************
    230 User logged in.
    Logged in!
    ==> SYST ...
    --> SYST

    215 Windows_NT
    done. ==> PWD ...
    --> PWD

    257 "/" is current directory.
    done.
    ==> TYPE I ...
    --> TYPE I

    200 Type set to I.
    done. changing working directory
    Prepended initial PWD to relative path:
    pwd: '/'
    old: 'sysman'
    new: '/sysman'
    ==> CWD (1) /sysman ...
    --> CWD /sysman

    250 CWD command successful.
    done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ...
    --> SIZE sm_6.5.0-15_A00.2.iso

    213 2888771584
    2888771584
    conaddr is: 143.166.11.10
    ==> PASV ...
    --> PASV

    227 Entering Passive Mode (143,166,11,10,201,249)
    trying to connect to 143.166.11.10 port 51705
    seconds 0.00, Created socket 4.
    done. ==> REST -1876255751 ...
    --> REST -1876255751

    501 Reply marker is invalid.

    REST failed, starting from scratch.

    ==> RETR sm_6.5.0-15_A00.2.iso ...
    --> RETR sm_6.5.0-15_A00.2.iso

    125 Data connection already open; Transfer starting.
    done.
    Length: 2888771584 (2.7G) (unauthoritative)

    0% [ ] 0 --.-K/s in 0.3s

    sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.
    Closed fd 3
    Closed fd 4

    I see, just realized that my wget don't have large-file support from "wget -V" will try recompile.

    Thanks for reports :)

    ReplyDelete
  30. M:\temp>wget -c ftp://dstrr:dstrr@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    --2011-12-05 11:09:17-- ftp://dstrr:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving localhost (localhost)... ::1, 127.0.0.1
    Connecting to localhost (localhost)|::1|:21... connected.
    Logging in as dstrr ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> EPSV ... done. ==> REST 2127124346 ... done.
    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G), 761647238 (726M) remaining (unauthoritative)

    74% [+++++++++++++++++++++++++++++++++++++++++> ] 2 145 974 138 44,9M/s
    C
    at this point i pressed Ctrl+C and breaked download
    Now i trying to resume

    M:\temp>wget -c ftp://dstrr:dstrr@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    --2011-12-05 11:09:19-- ftp://dstrr:*password*@localhost/mdrive/dell/sm_6.5.0-15_A00.2.iso
    => `sm_6.5.0-15_A00.2.iso'
    Resolving localhost (localhost)... ::1, 127.0.0.1
    Connecting to localhost (localhost)|::1|:21... connected.
    Logging in as dstrr ... Logged in!
    ==> SYST ... done. ==> PWD ... done.
    ==> TYPE I ... done. ==> CWD (1) /mdrive/dell ... done.
    ==> SIZE sm_6.5.0-15_A00.2.iso ... 2888771584
    ==> EPSV ... done. ==> REST -2139669990 ...
    REST failed, starting from scratch.

    ==> RETR sm_6.5.0-15_A00.2.iso ... done.
    Length: 2888771584 (2,7G) (unauthoritative)

    0% [ ] 0 --.-K/s in 0,04s

    sm_6.5.0-15_A00.2.iso: Invalid argument, closing control connection.

    please see, first run
    ==> EPSV ... done. ==> REST 2127124346 ... done.
    this is correct resume point

    second run
    ==> EPSV ... done. ==> REST -2139669990 ...
    file size is 2155297306. what is -2139669990?

    Thank You

    ReplyDelete
  31. nah silly me that large-file support isn't related that's for 64bit proc only. Since SIZEOF_OFF_T is 4 for 32bit...

    anyway the different REST is interesting (which is incorrect). Somehow REST at ftp scientific linux return resumable value.
    Will try at home later...

    Thanks

    ReplyDelete
  32. This problem is stat() used from gnulib (since wget 1.12) and always return the wrong filesize (st_size) if larger than 2GB. I'll try look deeper in the weekend...

    ReplyDelete
  33. Hi thanks for the build, 1.11 had some problems with sourceforge these days.

    But one problem is, your wget creates a empty file on a 404 instead of no file. And our scripts then keep pretending the file was already downloaded.

    Cheers

    ReplyDelete
  34. @anon
    fixed by forcing wget to use win32's _stat64 instead of gnulib's posix stat(). patched mswindows.h attached

    @TheOneRing
    give me your wget command first, I can't reproduce it

    ReplyDelete
  35. v:\dev-utils\bin\wget.exe --no-check-certificate -c -t 10 -O t:\kdelibs-4.7.4.tar.bz2 ftp://ftp.kde.org/pub/kde/stable/4.7.4/src/kdelibs-4.7.4.tar.bz2

    maybe it's caused by the -O paramenter

    ReplyDelete
  36. I agree that if the filesize 0 wget should delete it after received 404, dunno why they do this...

    as a workaround use -P t:\ instead of -O

    ReplyDelete
  37. hm yes but some urls we use are stuff like bitbucket.../1.0.1 and we have to rename them to tar.gz or stuff like that

    ReplyDelete
  38. Thanks a lot for fixing the 2GB bug!

    ReplyDelete
  39. Hi mate! Can you add this patch to WGET? Set stdout to binary...

    http://lists.gnu.org/archive/html/bug-wget/2009-05/msg00002.html

    ReplyDelete
  40. New release of Wget-1.14. Can you build it? Thanks!

    ReplyDelete
    Replies
    1. updated, but unteested, I'd rather wait for 1.14.x bugfix release though.
      Thanks for the head up!

      Delete
  41. wget 1.15 any time soon?

    ReplyDelete
    Replies
    1. Just checked it, there is no 1.15 yet. I think you misunderstand, this is just unofficial build, I'm no wget developer, you should check their homepage http://www.gnu.org/software/wget/ instead

      Delete
  42. Greetings, TumaGonx Zakkum
    Can You, please, recompile wget to lastest git source because of two issues:
    1. "Bad file descriptor" error if "-c" and unspecified lenght (fixed in commit b1838bdf from 14.11.2012) (cause problem when mirroring sites).
    Test command "wget -c www.google.com && wget -c www.google.com".
    2. Unlink() function give error if file busy in win32. Possible solution - replace unlink() with DeleteFile() or just comment checking at strings 1152/1153 (if (unlink (filename) < 0) return NULL;) in warc.c. Both solution cause non-deleted temporary files (but WARC begin to work).
    Test command - "wget --warc-file=1 www.google.com"

    And, please, can You describe, how do You compile so small file? I tried to compile wget, but recieve 4,5Mb (non-UPX) size - 500 kB Wget + 3Mb SSL + 1Mb Iconv (Looks like You use WinIconv instead)

    Best regards.
    PS. Sorry for bad English.

    ReplyDelete
    Replies
    1. Thanks dude the report and workaround,
      is [1] a new bug for 1.14 or to all version? and about [2] I dunno know what to say, considering there is a defect... maybe you could consult it with the devs first cause I'm not familiar with warc.

      That said, personally I'd rather wait for final bugfix release and I think (just a feeling) they're gonna make it soon... ah here you go:

      http://osspack32.googlecode.com/files/wget-git090313.exe
      untested as usual

      Why so small? Well, I'm addicted to squeeze it. What's your flags? have you tried my flag from wget -V?

      Delete
    2. Greetings
      Great Thanks!
      About issues - [1] exist only in 1.14. [2] - only in MinGW. Even in CygWin it (method of creation temporary files) work fine. Ok, I'll try to post it.
      About build - More Thanks.
      If i try to compile with CPFLAGS="-Os -s" + "upx --best --ultra-brute" (25% less than upx -9), i recieve - 2.9 Mb uncompressed/ 1.1 Mb UPXed (sorry, 4.5 Mb was with "-g" and , sure, without "--strip" key during debug). And 1.7/0.6 Mb without Iconv (with Win_Iconv. You sure use it).
      Compiled in fresh MinGW (only used mingwrt-3.18-mingw32_file64.diff patch) by string
      [code]./bootstrap && ./configure --with-ssl=openssl --with-libidn=/usr/local --with-libiconv-prefix=/usr/local --with-libssl-prefix=/usr/local/ssl --with-libintl-prefix=/usr/local CFLAGS="-DLARGEFILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_PC_NAME_MAX=255 -Os -s -msse2" LDFLAGS="-static -s" && make && make check[/code]

      Sorry for time waste.

      Delete
    3. I see... Now thats more realistic, BTW did you enable regex (via PCRE)? and fnmatch? they have no specific option to enable but autodetected by configure. If you also enable them then the difference could be:

      1. You're using mingw from mingw32.org, which is dwarf-2 based, which has extra debugging section per object file which you can't get rid of them unless using special flags "-fno-unwind-tables -fno-asynchronous-unwind-tables". I use mingw-w64 with SJLJ (no need for 64bit offset patch too)

      2. Because I build my gcc with "-Os" optimized libgcc and crt

      However if you don't enable them, the difference is still big... OpenSSL contribute the largest portion, how you build it, did you enable zlib, which version?

      Delete
    4. ultra-brute? Oh you're crazy, how long it takes? I can't stand that single threaded UPX to finished using my 2 Ghz cpu.

      Delete
  43. Greetings
    Great thanks for helping. After recompiling all with "-fno-unwind-tables -fno-asynchronous-unwind-tables" resulting size is 595Kb, (version with pcre - 620 Kb.) https://dl.dropbox.com/u/27457022/wget_nightly_wi.zip
    OpenSSL1.0.1e + zlib 1.2.7
    --ultra-brute UPX working with wget around 15 min. (30 min bootstrap + 10 min configure + 10 min build + 15 min UPX).
    A thousands more thanks!
    Best regards.

    ReplyDelete
  44. It seems to be flagged as a virus by VirusTotal:

    https://www.virustotal.com/en/file/cf8a9b5db43dd4820ea28e10786f3fac00cf294f793ead1aef86de75246f4495/analysis/

    ReplyDelete
    Replies
    1. Then help me to unflag it :)

      http://opensourcepack.blogspot.com/2013/03/list-of-upx-illiterate-antivirus.html

      Delete
  45. http://dl.dropboxusercontent.com/u/33728474/wget-1.13.4/locale.7z
    and
    http://dl.dropboxusercontent.com/u/33728474/wget-1.13.4/curl-ca-bundle.crt
    " ... are generating too much traffic and have been temporarily disabled! "

    Please upload elsewhere, thanks.

    ReplyDelete
  46. There is a new version of wget 1.15. http://ftp.gnu.org/gnu/wget/wget-1.15.tar.xz. Can you compile it. Thanks.

    ReplyDelete
  47. I tested this thoroughly. 1.15 (and the old 1.11.4) have same bug with timestamps:

    wget -N -O "hostsbadstamp" http://someonewhocares.org/hosts/zero/hosts
    timestamp of the -O output file is not updated.
    wget -N http://someonewhocares.org/hosts/zero/hosts

    timestamp is updated without the -O

    ReplyDelete
    Replies
    1. Could you file bugreport to wget team to confirm it?
      it seems not exactly the same issue reported earlier (which already fixed upstream).

      thanks

      Delete
    2. ahh did you read the message?
      WARNING: timestamping does nothing in combination with -O. See the manual

      Delete
  48. Wget 1.16 new release. Could you compile it for windows. Thanks.

    ReplyDelete
  49. Get latest versions from https://eternallybored.org/misc/wget/

    ReplyDelete
  50. New wget 1.16.2 today. Could you make windows release? Ty.

    ReplyDelete
  51. Херня красноглазая, блядь.
    HOW TO BUILD FOR WINDOWS ?
    where is source code, which has been changed ?

    ReplyDelete
  52. Wget 1.17 appeared today. Thanks.

    ReplyDelete
  53. Can you build curl-7.46.0 and wget 1.17.1. Thanks.

    ReplyDelete
  54. Wget 1.18 and curl 7.49.1 just appeared. Ty.

    ReplyDelete
  55. wget 1.19.1 was released. TY

    ReplyDelete
  56. Can you build aria2c 1.33.1? This release fixes a bug that causes high CPU usage in mingw build 1.33.0.

    ReplyDelete