bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wget-1.21.3-win32/64


From: WQ
Subject: Re: wget-1.21.3-win32/64
Date: Mon, 30 May 2022 14:57:05 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]