SourceForge has recently changed their configuration (to much frustration
due to issues like this) to block direct links completely. Going to a link
that is supposedly direct returns not the desired file, but the following:
<html><head><meta http-equiv="refresh" content="0"></head></html>
... and a 302 location header redirecting to some other URL, which
itself returns a 302 redirecting to somewhere else, and so on. For me,
it takes about six redirect iterations from the initial "direct" link
before finally getting to the real file.
It seems like wget's default value for the --max-redirect is zero or
something small. Combined with the above behavior, download.bat breaks. It
reports:
=
= Checking for signed update (attempt 1)...
GetGnuWin32 signed update found, verifying signature...
Verification Failure
... then repeats the same message for several subsequent attempts. Of
course the verification fails, because it's trying to verify an
almost-empty HTML file instead of the update zip file.
I was able to work around this issue by changing line 396 of download.bat
to add a '--max-redirect 10' option to the wget call:
bin\%WGETPROG% --max-redirect 10 --no-cache
http://%GETGNUWIN32_SITE%/%UPDATE_NAME%.zip 1>sf_diag.tmp 2>&1
I didn't see this issue on the bug tracker, and would have added it,
but SourceForge won't let me.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
GnuWin32-Users mailing list
GnuWin32-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
