[Bug 12835] New: Allow --link-dest to link to an optionally unexisting directory
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 Status: NEW Severity: enhancement Priority: P5 Component: core Assignee: way...@samba.org Reporter: julien+bugzilla-sa...@palard.fr QA Contact: rsync...@samba.org Found myself trying to hardlink between versions, but as I may rsync to a new server I may not having an old version to point to, so I had to use: rsync -rl --link-dest=$(ssh prod "cd /var/www; readlink -e current || echo .") static index.html prod:/var/www/$CI_COMMIT_SHA/ ssh prod "ln -nfs $CI_COMMIT_SHA" current Which is ugly. I'd prefer something like: rsync -rl --link-dest=current static index.html prod:/var/www/$CI_COMMIT_SHA/ ssh prod "ln -nfs $CI_COMMIT_SHA" current But warning / erroring on missing --link-dest sound legitimate, and we may not want to change this. If not, why not introduce a --link-dest-if-exists? Or a --ignore-missing-link-dest (in combination with the normal --link-dest)? -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 12806] Deleting in a row of hardlinked snapshots resets file permissions.
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 option has implications not suitable for other scenarios. For me it works just fine. Nevertheless, there should be a patch for rsync in order to overcome the questionable behaviour. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug: rsync erroneously changes modification time
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 change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug: rsync erroneously changes modification time
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 that have to be considered? rsync is only synching one way, it's always going from source to dest. Therefore source is always 'correct' whereas dest will be adjusted to match source. If you want a two way synching you'd need to call rsync twice with different parameters (and switched source/dest) or use a different tool. bye Fabi -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Bug: rsync erroneously changes modification time
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 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 have not changed. These options allow rsync to correct the incorrect timestamps without even looking inside of the files. If you are not 100% sure your file data matches you should not be using --size-only. On 06/11/2017 09:28 AM, max.power--- via rsync wrote: When a file of same length already exists at the destination then the command 'rsync --archive --size-only' (--archive is same as -rlptgoD) may change the modification time of the destination file even if no modification was made. Type the following commands in a terminal in order to reproduce the problem: $ mkdir source $ mkdir target $ echo "file one" > source/file $ echo "file two" > target/file $ srcstamp=2011.11 $ tgtstamp=2101.00 $ touch -t $srcstamp source/file $ touch -t $tgtstamp target/file $ stat -c "%y %s" source/file $ stat -c "%y %s" target/file Notice, that although the file in source/ and target/ folder contain different content they do not differ in size. Thus, there following command should not make any changes: $ rsync -rlptgoD --size-only source/ target There was indeed no backup performed, which can be verified by viewing the contents of the files: $ cat source/file $ cat target/file However, the modification time of the target file was updated to the same modification time as file in source/: $ stat -c "%y %s" source/file $ stat -c "%y %s" target/file Since the file was not modified the modification time should not be changed. Omitting the '-t' option in above rsync does not solve the problem because when a backup is actually performed then the modification time will simply be set to the current system time instead of the modification time of the source file. The same behaviour can be observed when using the flags -rlptgoD (or --archive) with the --checksum flag. Although it is highly unlikely that the files will differ if the checksums are the same, the modficaition should still not be changed for consistency reasons. - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., Kevin Korb Phone:(407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. ke...@futurequest.net (work) Orlando, Floridak...@sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., - ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html