Hi Tim, First, sorry for not subscribing the mailing lists. The reply is formatted manually, trying to keep the style :)
>> Hi there, >> >> >> >> I got this on a non-ASCII environment. The local path contains non-ASCII >> characters with OEM ANSI encoded. So, we should convert the server responded >> file name before it is concatenated to the local path. Not after that. Or, >> it will cause error in the next 'iconv' function . > >Hi, > >sounds reasonable, but please provide further info to reproduce the issue. > >I have a non-ASCII environment as well, and moved the whole Wget project into >some non-ASCII subdirectory (äöü/). At least some of the *-iri-* should have >failed, but all succeeded. > Platform: Windows, console code page is 936 'wget -V': " GNU Wget 1.19.1 built on mingw32. -cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls +ntlm +opie -psl +ssl/openssl " iconv: win-iconv Attaching compiled file is not a good idea. And you are on Linux. Others can get a substitute from https://eternallybored.org/misc/wget/ . And a screenshot is attached :) >Btw, your patch introduces a memory leak (fname_len_check will be >overwritten). And what about the 'else' case ? > I think: 'convert_fname' function will free the original memory when succeed. Same as 'fname' converted. leak? If 'replaced_filename' is provided, get the 'else' case, it is the local encoding and not need conversion. >Regards, Tim Regards, YX Hao
