Re: Large file support
Gisle Vanem <[EMAIL PROTECTED]> writes:
>> Another option was to simply set the (system) errno after the Winsock
>> operations, and have our own strerror that recognizes them. (That
>> assumes that Winsock errno values don't conflict with the system ones,
>> which I believe is the case.)
>
> That assumption is wrong I think.
> Winsock errors are in range 1 - 11004. Win32 API errors (from
> ) and libc errors (from ) *do* overlap. E.g. both
> EINTR and ERROR_TOO_MANY_OPEN_FILES both have the same value (4).
I'm not sure that we use the Win32 API calls and then check errno. If
we're doing that, we can set errno to GetLastError() + some large
constant specific to Wget after the calls.
> We must therefore be careful using strerror() with errno codes only
> and FormatMessage() with GetLastError (and WSAGetLastError). *Or*
> cook up a smarter strerror() replacement.
I would lean toward a smarter strerror replacement. I'll definitely
try to get it working before the release of 1.10 so we finally get
decent error messages on Windows.
> #undef strerror
> char *win_strerror (int err)
> {
> static char buf[512];
> char *p;
>
> if (err >= 0 && err < sys_nerr)
> {
> strncpy (buf, strerror(err), sizeof(buf)-1);
> buf [sizeof(buf)-1] = '\0';
> }
> else
> {
> if (!get_winsock_error (err, buf, sizeof(buf)) &&
> !FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM, NULL, err,
> LANG_NEUTRAL, buf, sizeof(buf)-1, NULL))
>sprintf (buf, "Unknown error %d (%#x)", err, err);
> }
This is a good start -- but doesn't it suffer from the confusion
between EINTR and ERROR_TOO_MANY_OPEN_FILES?
Re: Large file support
"Hrvoje Niksic" wrote:
errno/WSAGetLastError() handling and reporting is still broken for all
Win32 compilers. Search for SET_ERRNO() in the mail-archive.
I remember that. At the time I disliked the idea of using the
SET/GET_ERRNO pair instead of just using and assigning to errno.
Another option was to simply set the (system) errno after the Winsock
operations, and have our own strerror that recognizes them. (That
assumes that Winsock errno values don't conflict with the system ones,
which I believe is the case.)
That assumption is wrong I think.
Winsock errors are in range 1 - 11004. Win32 API errors (from )
and libc errors (from ) *do* overlap. E.g. both EINTR and
ERROR_TOO_MANY_OPEN_FILES both have the same value (4).
We must therefore be careful using strerror() with errno codes only
and FormatMessage() with GetLastError (and WSAGetLastError). *Or*
cook up a smarter strerror() replacement. It is "normal" to assume that
err_code < sys_nerr belongs to libc (MSVCRT.DLL). Use with care:
#undef strerror
char *win_strerror (int err)
{
static char buf[512];
char *p;
if (err >= 0 && err < sys_nerr)
{
strncpy (buf, strerror(err), sizeof(buf)-1);
buf [sizeof(buf)-1] = '\0';
}
else
{
if (!get_winsock_error (err, buf, sizeof(buf)) &&
!FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM, NULL, err,
LANG_NEUTRAL, buf, sizeof(buf)-1, NULL))
sprintf (buf, "Unknown error %d (%#x)", err, err);
}
/* strip trailing '\r\n' or '\n'. */
if ((p = strrchr(buf,'\n')) != NULL && (p - buf) >= 2)
*p = '\0';
if ((p = strrchr(buf,'\r')) != NULL && (p - buf) >= 1)
*p = '\0';
return buf;
}
static char *
get_winsock_error (int err, char *buf, size_t len)
{
char *p;
switch (err)
{
case WSAEINTR:
p = "Call interrupted.";
break;
case WSAEBADF:
p = "Bad file";
break;
.
--gv
Re: Large file support
Gisle Vanem <[EMAIL PROTECTED]> writes: > "Hrvoje Niksic" wrote: > >> In other words, large files now work on Windows? I must admit, that >> was almost too easy. :-) > > Don't open the champagne bottle just yet :) Too late, the bottle is already empty. :-) >> Now could someone try this with Borland and/or Watcom and MingW? I'm >> pretty sure I broke them in some places, but it's near impossible to >> fix it without having the compilers available for testing. > > Patch attached. Thanks. Note that I fixed compilation under Borland in the meantime, because I found that the Borland command-line tools are available for free download. > errno/WSAGetLastError() handling and reporting is still broken for all > Win32 compilers. Search for SET_ERRNO() in the mail-archive. I remember that. At the time I disliked the idea of using the SET/GET_ERRNO pair instead of just using and assigning to errno. Another option was to simply set the (system) errno after the Winsock operations, and have our own strerror that recognizes them. (That assumes that Winsock errno values don't conflict with the system ones, which I believe is the case.)
Re: Large file support
"Hrvoje Niksic" wrote: In other words, large files now work on Windows? I must admit, that was almost too easy. :-) Don't open the champagne bottle just yet :) Now could someone try this with Borland and/or Watcom and MingW? I'm pretty sure I broke them in some places, but it's near impossible to fix it without having the compilers available for testing. Patch attached. errno/WSAGetLastError() handling and reporting is still broken for all Win32 compilers. Search for SET_ERRNO() in the mail-archive. And also here: http://www.mail-archive.com/wget%40sunsite.dk/msg06475.html *_ERRNO() is in my working copy. Drop that until I come up with a use for them. --gv diff -u3 -Hb -r CVS-Latest/src/mswindows.h src/mswindows.h --- CVS-Latest/src/mswindows.h Fri Feb 25 23:23:21 2005 +++ src/mswindows.h Sat Feb 26 13:54:53 2005 @@ -83,7 +83,11 @@ /* Define a wgint type under Windows. */ typedef __int64 wgint; #define SIZEOF_WGINT 8 +#ifdef __GNUC__ +#define WGINT_MAX 9223372036854775807LL +#else #define WGINT_MAX 9223372036854775807I64 +#endif #define str_to_wgint str_to_int64 __int64 str_to_int64 (const char *, char **, int); @@ -99,7 +103,7 @@ # define fstat(fd, buf) _fstati64 (fd, buf) #endif -#if defined(_MSC_VER) +#if defined(_MSC_VER) || defined(__MINGW32__) # define struct_stat struct _stati64 #elif defined(__BORLANDC__) # define struct_stat struct stati64 diff -u3 -Hb -r CVS-Latest/src/sysdep.h src/sysdep.h --- CVS-Latest/src/sysdep.h Wed Feb 23 21:21:04 2005 +++ src/sysdep.hSat Feb 26 13:43:34 2005 @@ -108,6 +108,17 @@ #endif #endif +/* Hacks for setting/getting errno / h_errno. */ +#ifdef WINDOWS +# define GET_ERRNO() errno = WSAGetLastError() +# define SET_ERRNO(e) WSASetLastError (errno = (e)) +# define SET_H_ERRNO(e) WSASetLastError (e) +#else +# define GET_ERRNO() ((void)0) +# define SET_ERRNO(e) ((void)(errno = (e))) +# define SET_H_ERRNO(e) ((void)(h_errno = (e))) +#endif + /* Define a large integral type useful for storing large sizes that exceed sizes of one download, such as when printing the sum of all downloads. Note that this has nothing to do with large file @@ -127,7 +138,7 @@ typedef long long LARGE_INT; # define LARGE_INT_FMT "%lld" # else -# if _MSC_VER +# if defined(_MSC_VER) || defined(__MINGW32__) || defined(__WATCOMC__) /* Use __int64 under Windows. */ typedef __int64 LARGE_INT; # define LARGE_INT_FMT "%I64"
Re: 2GB+ resume problem
Please note that Wget 1.9.x doesn't support downloading of 2G+ files. To download large files, get the CVS version of Wget (see http://wget.sunsite.dk for instructions.)
2GB+ resume problem
--06:45:07-- ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/sarg e-i386-1.iso (try: 2) => `sarge-i386-1.iso' ==> CWD not required. ==> SIZE sarge-i386-1.iso ... done. ==> PORT ... done.==> REST 1197080576 ... done. ==> RETR sarge-i386-1.iso ... done. 100%[+++===>] 2,147,471,616 107.07K/s ETA 00:00A ssertion failed: insz <= dlsz, file progress.c, line 704 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --09:16:10-- ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/sarg e-i386-1.iso => `sarge-i386-1.iso' Resolving ftp.fsn.hu... 195.228.252.133, 195.228.252.132 Connecting to ftp.fsn.hu[195.228.252.133]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/CDROM-Images/debian-unofficial/sarge-dvd ... done. ==> SIZE sarge-i386-1.iso ... done. ==> PORT ... done.==> REST -2147476804 ... REST failed, starting from scratch. ==> RETR sarge-i386-1.iso ... done. [ <=> ] 134,241,756 112.94K/s i don't really care about the progress, but it resetted the download from 2gb to 0,13 thx dennis
