Re: wget-1.21.3-win32/64
To be 100% sure I retested it with wget 32bit : 64bit : So we know it's not 32/64 related On 31/05/2022 15:12, ge...@mweb.co.za wrote: @WQ, now that's impressive! I still wonder how that came about,though ... @Tim, as soon a I have a moment I will take that exe and try it out with my use cases and any new options that might be useful to me. Anything interesting, I'll let you know. Gerd *From: *"WQ" *To: *"Tim Ruehsen" , ge...@mweb.co.za *Cc: *"bug-wget" , "darnir" *Sent: *Tuesday, May 31, 2022 2:35:41 PM *Subject: *Re: wget-1.21.3-win32/64 Hi, I just tested the wget2 executable on my Win10 with exactly the same command : *wget2.exe -O TargetPath\TargetFile http://source* And now it's working everywhere, *even on the Netgear* As you can see, I now get the original DateTme-stamp under all circmstances. So that's great news, and will start to use wget2 from now on. But, to be clear, I did not do any other tests, so I can't tell if all wget2 functionality is working properly. Thanks for having informed about the exe ! Kind regards Walter On 31/05/2022 12:54, Tim Rühsen wrote: On 30.05.22 14:57, WQ wrote: 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 it remains unclear why the original datetime works locally and on the Thecus, even if it should not (as documented) When a local wget (with/without -O) is done followed by a move to the Netgear, the time-stamp is ok, I tested that before too. But I'm trying to avoid the move as this involves extra time, especially with giga-files. Yes, a real renaming mechanism, is a missing option. I didn't know about wget2, but it seems there are no compiled versions available. With the latest release of wget2 (v2.0.1), there is a .exe version available. It doesn't have all features yet, but hopefully works. I can only test it with a Windows emulation (wine) on Linux. Go to the bottom at https://gitlab.com/gnuwget/wget2/-/tags/v2.0.1 Regards, Tim
Re: wget-1.21.3-win32/64
Hi, I just tested the wget2 executable on my Win10 with exactly the same command : *wget2.exe -O TargetPath\TargetFile http://source* And now it's working everywhere, *even on the Netgear* As you can see, I now get the original DateTme-stamp under all circmstances. So that's great news, and will start to use wget2 from now on. But, to be clear, I did not do any other tests, so I can't tell if all wget2 functionality is working properly. Thanks for having informed about the exe ! Kind regards Walter On 31/05/2022 12:54, Tim Rühsen wrote: On 30.05.22 14:57, WQ wrote: 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 it remains unclear why the original datetime works locally and on the Thecus, even if it should not (as documented) When a local wget (with/without -O) is done followed by a move to the Netgear, the time-stamp is ok, I tested that before too. But I'm trying to avoid the move as this involves extra time, especially with giga-files. Yes, a real renaming mechanism, is a missing option. I didn't know about wget2, but it seems there are no compiled versions available. With the latest release of wget2 (v2.0.1), there is a .exe version available. It doesn't have all features yet, but hopefully works. I can only test it with a Windows emulation (wine) on Linux. Go to the bottom at https://gitlab.com/gnuwget/wget2/-/tags/v2.0.1 Regards, Tim
Re: wget-1.21.3-win32/64
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.
I guess it is what stops us "exe file consumers"
Indeed, I would have been busy testing now.
a Windows port may not be all that trivial ...
Probably not, but not having the compiler/linker is a show-stopper
2) the errant behaviour of the Netgear - I assume there are no software fixes
for this?
Negative !
Even worse, I asked several times Netgear Support what might be the
reason, . and never got any answer ! For me reason enough to never
consider buying Netgear again.
Kind regards
Walter
On 30/05/2022 16:22, ge...@mweb.co.za wrote:
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 file consumers" from exploring the new version. On the other
hand, a Windows port may not be all that trivial ...
When I let the findings pass before my inner self (... ;-) it seems we have two
items left to explain:
1) the time stamp works where it shouldn't (based on wget 1.18 from 2016.) There is a possibility that someone found it useful to fix that -O behaviour and just did it.
2) the errant behaviour of the Netgear - I assume there are no software fixes
for this?
Regards,
Gerd
- Original Message -
From: "WQ"
To: ge...@mweb.co.za
Cc: "bug-wget" , "darnir"
Sent: Monday, May 30, 2022 2:57:05 PM
Subject: Re: wget-1.21.3-win32/64
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 it remains unclear why the
original datetime works locally and on the Thecus, even if it should not
(as documented)
When a local wget (with/without -O) is done followed by a move to the
Netgear, the time-stamp is ok, I tested that before too. But I'm trying
to avoid the move as this involves extra time, especially with giga-files.
Yes, a real renaming mechanism, is a missing option.
I didn't know about wget2, but it seems there are no compiled versions
available.
Thank you
Kind regards
Walter
On 30/05/2022 13:25, ge...@mweb.co.za wrote:
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 the SMB ("Samba") protocol, implemented
correctly or otherwise.
Some of your findings could only be explained by this last assumptions.
Wget documentation is pretty clear about timestamping and if the servers you
download from are doing things accordingly there should be no issues like you
describe.
(By the way: Have you considered investigating wget2, the newer implementation,
which may be doing things differently, especially in the area that concerns you
here.)
One thing that the wget documentation is also quite clear about is the use of the -O feature. It seems that
you use it to download a file "xxx" to a destination file that you want to name "yyy".
Which is more or less what it seems to do. Except: (!) the -O feature, it says, only serves to give a
filename to the stdout output that captures the downloaded file(s) and will always carry the current time as
a timestamp. Why some of your results disagree with this remains to be explained. I also look with a sense of
wonder at your description of the syntax of the -O argument as "path/file" - not something that
fits well with the typical Windows syntax.
My suggestions for someone like you that "absolutely depends" on correct
transmission of the original timestamps are these:
1) Study the behaviour of the NASes; they don't seem to be consistent.
2) Avoid the -O feature as a way to rename downloaded files; the documented
behaviour is in direct conflict with what you wan
3) Consider a scripted solution that downloads the file to a local drive on
your system and then copies/moves it to the NAS using Windows. That will avoid
the -O problem and also make it clear who manipulates the timestamp in what
way. This would be useful even if just used for some tests.
(Personally, I use wget a lot with the -i option (download from a list of URIs
in a file) and would LOVE a renaming mechanism --- in wget2 ifnot before ..)
Re: wget-1.21.3-win32/64
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 it remains unclear why the
original datetime works locally and on the Thecus, even if it should not
(as documented)
When a local wget (with/without -O) is done followed by a move to the
Netgear, the time-stamp is ok, I tested that before too. But I'm trying
to avoid the move as this involves extra time, especially with giga-files.
Yes, a real renaming mechanism, is a missing option.
I didn't know about wget2, but it seems there are no compiled versions
available.
Thank you
Kind regards
Walter
On 30/05/2022 13:25, ge...@mweb.co.za wrote:
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 the SMB ("Samba") protocol, implemented
correctly or otherwise.
Some of your findings could only be explained by this last assumptions.
Wget documentation is pretty clear about timestamping and if the servers you
download from are doing things accordingly there should be no issues like you
describe.
(By the way: Have you considered investigating wget2, the newer implementation,
which may be doing things differently, especially in the area that concerns you
here.)
One thing that the wget documentation is also quite clear about is the use of the -O feature. It seems that
you use it to download a file "xxx" to a destination file that you want to name "yyy".
Which is more or less what it seems to do. Except: (!) the -O feature, it says, only serves to give a
filename to the stdout output that captures the downloaded file(s) and will always carry the current time as
a timestamp. Why some of your results disagree with this remains to be explained. I also look with a sense of
wonder at your description of the syntax of the -O argument as "path/file" - not something that
fits well with the typical Windows syntax.
My suggestions for someone like you that "absolutely depends" on correct
transmission of the original timestamps are these:
1) Study the behaviour of the NASes; they don't seem to be consistent.
2) Avoid the -O feature as a way to rename downloaded files; the documented
behaviour is in direct conflict with what you wan
3) Consider a scripted solution that downloads the file to a local drive on
your system and then copies/moves it to the NAS using Windows. That will avoid
the -O problem and also make it clear who manipulates the timestamp in what
way. This would be useful even if just used for some tests.
(Personally, I use wget a lot with the -i option (download from a list of URIs
in a file) and would LOVE a renaming mechanism --- in wget2 ifnot before ..)
More help could be useful from people that can shed some light on how NASes
work and - if applicable - where the different versions and implementatios of
Samba can play a role.
One last thought: your source server(s) also play(s) a role. If FTP is
supported that may be another avenue to explore.
Good luck!
- Original Message -
From: "WQ"
To: "bug-wget" , "darnir"
Sent: Monday, May 30, 2022 8:30:35 AM
Subject: Fwd: wget-1.21.3-win32/64
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 TargetPath/TargetFile *is
locally on a PC (according to above it should not be possible)
* does have the original DateTime when *-O TargetPath/TargetFile *is
on the Thecus NAS (according to above it should not possible)
* does *NOT *have the original DateTime when *-O TargetPath/TargetFile
*is on the Netgear NAS
I have always been using *-O TargetPath/TargetFile *to download a file
directly into *TargetPath *with the name *TargetFile
*Thanks for helping me out*
*
Kind regards
Walter
Forwarded Message
Subject:wget-1.21.3-win32/64
Date: Fri, 15 Apr 2022 23:54:10 +0200
From: gc394625
To: bug-wget@gnu.org
Hi,
Actually I'm using wget-1.21.3-win32/64 and I have (since long) a weird
problem :
I have an "old" Thecus N2100 NAS and a "less old" Netgear RN102 (newest
Firmware). They are used in Windows with their UNC (\\NAS\Folder\).
*Netgear RN102:*
When downloading files from the Internet with WGET,*the original
Date/Time stamp of the files is lost* (it becomes the
download-Date/Time). To
Fwd: wget-1.21.3-win32/64
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 TargetPath/TargetFile *is locally on a PC (according to above it should not be possible) * does have the original DateTime when *-O TargetPath/TargetFile *is on the Thecus NAS (according to above it should not possible) * does *NOT *have the original DateTime when *-O TargetPath/TargetFile *is on the Netgear NAS I have always been using *-O TargetPath/TargetFile *to download a file directly into *TargetPath *with the name *TargetFile *Thanks for helping me out* * Kind regards Walter Forwarded Message Subject:wget-1.21.3-win32/64 Date: Fri, 15 Apr 2022 23:54:10 +0200 From: gc394625 To: bug-wget@gnu.org Hi, Actually I'm using wget-1.21.3-win32/64 and I have (since long) a weird problem : I have an "old" Thecus N2100 NAS and a "less old" Netgear RN102 (newest Firmware). They are used in Windows with their UNC (\\NAS\Folder\). *Netgear RN102:* When downloading files from the Internet with WGET,*the original Date/Time stamp of the files is lost* (it becomes the download-Date/Time). To be clear, this only concerns WGET ! Windows-copies keep the original Date/Time ! *Thecus N2100:* Simultaneous downloading of the same files (same PC, same WGET) to the Thecus *will retain the original Date/Time* like it's done also on a normal PC-drive. Same known behaviour since WinXP upto actual Win10. I have never been able to find a solution for the Netgear, so actually couldn't use it for all my needs. What is WGET doing after the file has been downloaded to set the correct Date/time (on the Thecus) What could be the reason ? (How) can I solve this ? Any experinces with other NAS-brands in combination with WGET ? This Date/Time behaviour is crucial for me for purchasing a new NAS !!! It MUST work. Thanks for helping Kind regards Walter
[Bug-wget] Fwd: Fwd: Re: RESEND1: wget-1.20-win32
*Also :* https://fpdownload.macromedia.com/pub/flashplayer/latest/help/install_flash_player.exe Forwarded Message Subject:Fwd: Re: [Bug-wget] RESEND1: wget-1.20-win32 Date: Thu, 16 May 2019 14:31:49 +0200 From: WQ To: bug-wget@gnu.org *Also :* https://saimei.ftp.acc.umu.se/mirror/ipfire.org/releases/ipfire-2.x/2.23-core131/ipfire-2.23.x86_64-full-core131.iso Forwarded Message Subject:Re: [Bug-wget] RESEND1: wget-1.20-win32 Date: Sun, 12 May 2019 18:57:38 +0200 From: WQ To: bug-wget@gnu.org *1.20.3 : * *1.20: *** ** *Please see also what I wrote and the picture in my original mail (below)* Thanks Walter On 12/05/2019 17:45, Darshit Shah wrote: Could you please let us know which sites? * WQ [190512 17:41]: See below ! FYI: The updated 1.20.3 still gives problems with some sites Forwarded Message Subject:wget-1.20-win32 Date: Wed, 17 Apr 2019 01:18:01 +0200 From: WQ To: bug-wget@gnu.org Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter
[Bug-wget] Fwd: Re: RESEND1: wget-1.20-win32
*Also :* https://saimei.ftp.acc.umu.se/mirror/ipfire.org/releases/ipfire-2.x/2.23-core131/ipfire-2.23.x86_64-full-core131.iso Forwarded Message Subject:Re: [Bug-wget] RESEND1: wget-1.20-win32 Date: Sun, 12 May 2019 18:57:38 +0200 From: WQ To: bug-wget@gnu.org *1.20.3 : * *1.20: *** ** *Please see also what I wrote and the picture in my original mail (below)* Thanks Walter On 12/05/2019 17:45, Darshit Shah wrote: Could you please let us know which sites? * WQ [190512 17:41]: See below ! FYI: The updated 1.20.3 still gives problems with some sites Forwarded Message Subject:wget-1.20-win32 Date: Wed, 17 Apr 2019 01:18:01 +0200 From: WQ To: bug-wget@gnu.org Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter
Re: [Bug-wget] RESEND1: wget-1.20-win32
*1.20.3 : * *1.20: *** ** *Please see also what I wrote and the picture in my original mail (below)* Thanks Walter On 12/05/2019 17:45, Darshit Shah wrote: Could you please let us know which sites? * WQ [190512 17:41]: See below ! FYI: The updated 1.20.3 still gives problems with some sites Forwarded Message Subject:wget-1.20-win32 Date: Wed, 17 Apr 2019 01:18:01 +0200 From: WQ To: bug-wget@gnu.org Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter
[Bug-wget] RESEND1: wget-1.20-win32
See below ! FYI: The updated 1.20.3 still gives problems with some sites Forwarded Message Subject:wget-1.20-win32 Date: Wed, 17 Apr 2019 01:18:01 +0200 From: WQ To: bug-wget@gnu.org Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter
[Bug-wget] wget-1.20-win32
Hi, I'm using wget-1.20-win32 (not wget-1.20.3-win32 because there is a problem). During download, there is a problem with the "scrolling" name, the last character character of the name is repeated some time : Kind regards Walter
