[Bug 12835] New: Allow --link-dest to link to an optionally unexisting directory

2017-06-12 Thread just subscribed for rsync-qa from bugzilla via rsync
https://bugzilla.samba.org/show_bug.cgi?id=12835 Bug ID: 12835 Summary: Allow --link-dest to link to an optionally unexisting directory Product: rsync Version: 3.1.3 Hardware: All OS: All

[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.

2017-06-12 Thread just subscribed for rsync-qa from bugzilla via rsync
https://bugzilla.samba.org/show_bug.cgi?id=12806 --- Comment #5 from Heinz-Willi Wyes --- Lars Ellenberg provided a workaround for the behaviour. Using rsync -d --delete --super `mktemp -d`/ snapshots/2017-05-26-15-00-53/ plays the trick. Not sure whether the --super

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

Re: Bug: rsync erroneously changes modification time

2017-06-12 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

Re: Bug: rsync erroneously changes modification time

2017-06-12 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