Re: wget-1.21.3-win32/64

[address@hidden]

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" <wquatan@belgacom.net>
To: gerdd@mweb.co.za
Cc: "bug-wget" <bug-wget@gnu.org>, "darnir" <darnir@gnu.org>
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, gerdd@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" <wquatan@belgacom.net>
> To: "bug-wget" <bug-wget@gnu.org>, "darnir" <darnir@gnu.org>
> 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 <gc394625@belgacom.net>
> 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