Re: wget-1.21.3-win32/64

2022-05-30 Thread WQ
Hi, My documentation may be outdated ... Don't think so, that's what I found in the online documentation too (but is in contradiction with the results of my test-cases) BTW, I'm using wget-1.21.3-win32/64, but I know the same happened already in wget-1.18. For prior versions I don't remember.

Re: wget-1.21.3-win32/64

2022-05-30 Thread ge...@mweb.co.za
Hi, This, I believe, now highlights the open points. Let's see what the experts have to say , especially about the things that work unexpectedly (!?!) My documentation may be outdated ... That point about a pre-built wget2 for Windows is a very good one. I guess it is what stops us "exe

Re: wget-1.21.3-win32/64

2022-05-30 Thread WQ
Hi, Thank you for having replied anyway ! The testing I did was always with the same server and file. So I'm 100% sure about the results (different behaviour on the Netgear) When I wrote "path/file" then I did mean something like F:\Download\thefile.txt I know the documented -O feature, but

Re: wget-1.21.3-win32/64

2022-05-30 Thread ge...@mweb.co.za
Hi, I am not normally concerned with solving issues surrounding wget, but I use it a lot myself (mostly on Windows, like you) so the problem you describe intrigues me. I don't use a NAS, so I can only assume that both of yours (as well as your yet unknown next one) would use some form of

Fwd: wget-1.21.3-win32/64

2022-05-30 Thread WQ
Hi, Let me remind my issue in the mail below . Some additional information : I'm using this command : *wget.exe -O TargetPath/TargetFile http://source* In the meanwhile I found this : And now I'm completely lost because the*downloaded file** * * does have the original DateTime when *-O