Re: Bug: rsync erroneously changes modification time

2017-06-14 Thread max.power--- via rsync
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

Re: Bug: rsync erroneously changes modification time

2017-06-12 Thread 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 for most replies to avoid omitting the mailing list. To unsubscribe or ch

Re: Bug: rsync erroneously changes modification time

2017-06-11 Thread Fabian Cenedese via rsync
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

Re: Bug: rsync erroneously changes modification time

2017-06-11 Thread max.power--- via rsync
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

Re: Bug: rsync erroneously changes modification time

2017-06-11 Thread Kevin Korb via rsync
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