Ok, that clears things up.
Thanks.
Quoting Paul Slootman via rsync :
On Mon 12 Jun 2017, max.power--- via rsync wrote:
How exactly does rsync determine that the copy has the incorrect timestamp
and not the source file?
The source by definition is correct.
Paul
--
Please use reply-all fo
On Mon 12 Jun 2017, max.power--- via rsync wrote:
> How exactly does rsync determine that the copy has the incorrect timestamp
> and not the source file?
The source by definition is correct.
Paul
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or ch
At 08:11 12.06.2017, max.power--- via rsync wrote:
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>How exactly does rsync determine that the copy has the incorrect
>timestamp and not the source file?
>Does it assume that the copy must be incorrect or are there other
>criteria t
How exactly does rsync determine that the copy has the incorrect
timestamp and not the source file?
Does it assume that the copy must be incorrect or are there other
criteria that have to be considered?
Quoting Kevin Korb via rsync :
Whenever you use --times (included in --archive) rsync w
Whenever you use --times (included in --archive) rsync will fix
incorrect time stamps. The only thing --size-only is doing is keeping
the incorrect data instead of replacing it.
The purpose of these options is to "fix" a copy done in a way that did
not preserve timestamps but the data is known to