On 10/23/18 9:07 AM, Darshit Shah wrote:
> On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>> Currently when a download with timestamping enabled gets interrupted,
>> the timestamp of the resulting file ends up being the current time and
>> when wget is re-executed after connectivity is
On 10/23/18 9:07 AM, Darshit Shah wrote:
> On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>> Currently when a download with timestamping enabled gets interrupted,
>> the timestamp of the resulting file ends up being the current time and
>> when wget is re-executed after connectivity is
On October 22, 2018 11:49:12 PM UTC, Dave Warren wrote:
>Currently when a download with timestamping enabled gets interrupted,
>the timestamp of the resulting file ends up being the current time and
>when wget is re-executed after connectivity is restored the local file
>is then seen as newer a
Currently when a download with timestamping enabled gets interrupted,
the timestamp of the resulting file ends up being the current time and
when wget is re-executed after connectivity is restored the local file
is then seen as newer and skipped.
robocopy handles this a little differently, by
