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
@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/ | 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: BQ_BEGIN 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 | https://gitlab.com/gnuwget/wget2/-/tags/v2.0.1 ] Regards, Tim BQ_END
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
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 OpenPGP_signature Description: OpenPGP digital signature
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,
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
> ..)
>
>
> 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
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 be clear, this only concerns WGET !
Windows-copies keep the original Date/Time !
*Thecus N2100:*
Simultaneous
Re: wget-1.21.3-win32/64
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 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
Re: wget-1.21.3-win32/64
Hi Tim,
Thanks for replying !
The older Thecus (which has no date-time-problem) uses EXT3
The newer Netgear uses EXT4
But I can't imagine that could a reason.
On both I have full Admin rights (on any folder)
I think I'm using the latest wget-1.21.3-win32/64
Kind regards
Walter
On 22/04/2022 20:23, Tim Rühsen wrote:
On 15.04.22 23:54, gc394625 wrote:
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
Hi,
are you sure that both directories (on the two different NASes) have
exactly the same permissions ? Maybe also check that both have the
same file system (I can only guess that both use NTFS, but I am not a
Win expert).
Then make sure that you have the latest wget, best from
https://eternallybored.org/misc/wget/
The code to set the file time is in src/utils.c:
/* "Touch" FILE, i.e. make its mtime ("modified time") equal the time
specified with TM. The atime ("access time") is set to the current
time. */
void
touch (const char *file, time_t tm)
{
struct utimbuf times;
times.modtime = tm;
times.actime = time (NULL);
if (utime (file, ) == -1)
logprintf (LOG_NOTQUIET, "utime(%s): %s\n", file, strerror (errno));
}
'utime()' on Windows is emulated by gnulib - so there is a chance that
the latest wget works differently as it contains a newer gnulib code.
But if utime() fails, you should see that log output.
The gnulib Windows emulation code is in lib/utime.c, if you are
interested in the details.
Regards, Tim
Re: wget-1.21.3-win32/64
On 15.04.22 23:54, gc394625 wrote:
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
Hi,
are you sure that both directories (on the two different NASes) have
exactly the same permissions ? Maybe also check that both have the same
file system (I can only guess that both use NTFS, but I am not a Win
expert).
Then make sure that you have the latest wget, best from
https://eternallybored.org/misc/wget/
The code to set the file time is in src/utils.c:
/* "Touch" FILE, i.e. make its mtime ("modified time") equal the time
specified with TM. The atime ("access time") is set to the current
time. */
void
touch (const char *file, time_t tm)
{
struct utimbuf times;
times.modtime = tm;
times.actime = time (NULL);
if (utime (file, ) == -1)
logprintf (LOG_NOTQUIET, "utime(%s): %s\n", file, strerror (errno));
}
'utime()' on Windows is emulated by gnulib - so there is a chance that
the latest wget works differently as it contains a newer gnulib code.
But if utime() fails, you should see that log output.
The gnulib Windows emulation code is in lib/utime.c, if you are
interested in the details.
Regards, Tim
OpenPGP_signature
Description: OpenPGP digital signature
