[Bug 785445] New: bug in rsync when copying hard links with --inplace
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c0 Summary: bug in rsync when copying hard links with --inplace Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Critical Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: pvh@oma.be QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=509819) --> (http://bugzilla.novell.com/attachment.cgi?id=509819) tarball of the source directory User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0 I have seen the following error messages while backing up the firefox common translations, but the same also happens with the thunderbird and seamonkey translations. ---------- WARNING: usr/lib64/firefox/extensions/langpack-da@firefox.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd failed verification -- update retained (will try again). WARNING: usr/lib64/firefox/extensions/langpack-en-GB@firefox.mozilla.org/chrome/en-GB/locale/browser/devtools/responsiveUI.properties failed verification -- update retained (will try again). WARNING: usr/lib64/firefox/extensions/langpack-en-GB@firefox.mozilla.org/chrome/en-GB/locale/pdfviewer/viewer.properties failed verification -- update retained (will try again). ERROR: usr/lib64/firefox/extensions/langpack-en-GB@firefox.mozilla.org/chrome/en-GB/locale/pdfviewer/viewer.properties failed verification -- update retained. WARNING: usr/lib64/thunderbird/extensions/langpack-da@thunderbird.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd failed verification -- update retained (will try again). rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1526) [generator=3.0.7] --------- The command I used was /usr/bin/rsync -avxH --inplace --numeric-ids --delete --delete-excluded --exclude-from=/private/backup/snapshots/conf/distros.excl vaps005:/ /private/backup/rsync/distros/vaps005/root I have seen essentially the same problem on two completely different backup servers. One is running openSUSE 12.2, the other Ubuntu 10.04. Also the file system doesn't seem involved as I have seen identical problems copying from ext4 -> ext4, ext4 -> Btrfs, and Btrfs -> Btrfs. The only thing these systems have in common are firefox and rsync (version 3.0.9 on the openSUSE system and 3.0.7 on the Ubuntu system). I assume this is caused by a bug in rsync triggered by simultaneously using the -H and --inplace flags -- likely the inplace logic doesn't take side effects from hard links into account. But I have not investigated this in detail. Reproducible: Always Steps to Reproduce: 1. Download these tarballs http://homepage.oma.be/pvh/suse/source.tar.gz and http://homepage.oma.be/pvh/suse/backup.tar.gz 2. Unpack the tarballs in a suitable place 3. Run the command rsync -avxH --inplace --delete /path/to/source/extensions /path/to/backup/ repeatedly. Actual Results: On the first invocation of rsync, it will appear to work normally (note that you will NOT get the error message shown above). However, when you run rsync a second time you will see that it is still trying to modify the files in the backup directory. So it is evident that rsync failed the first time (and also the second time). You can repeat this as often as you like, the process will never converge. Expected Results: Rsync should sync the the files on the first invocation, and not do anything on any subsequent invocations. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c1 --- Comment #1 from Peter van Hoof <pvh@oma.be> 2012-10-17 10:38:04 UTC --- Created an attachment (id=509831) --> (http://bugzilla.novell.com/attachment.cgi?id=509831) tarball of the backup directory -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |vcizek@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c2 Vitezslav Cizek <vcizek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |vcizek@suse.com --- Comment #2 from Vitezslav Cizek <vcizek@suse.com> 2012-11-01 16:05:07 CET --- I don't get your warning messages, however the rsync never converges and is overwritten on each rsync run. Here's why: In the backup directory, datetimepicker.dtd files in several langpacks are the same files (same inode = hard links)
ls -i backup/extensions/langpack-cs@firefox.mozilla.org/chrome/cs/locale/cs/global/datetimepicker.dtd 4758422 backup/extensions/langpack-cs@firefox.mozilla.org/chrome/cs/locale/cs/global/datetimepicker.dtd
ls -i backup/extensions/langpack-da@firefox.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd 4758422 backup/extensions/langpack-da@firefox.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd
On the contrary, in the source, these files don't point to the same inode.
ls -i source/extensions/langpack-cs@firefox.mozilla.org/chrome/cs/locale/cs/global/datetimepicker.dtd 4872032 source/extensions/langpack-cs@firefox.mozilla.org/chrome/cs/locale/cs/global/datetimepicker.dtd
ls -i source/extensions/langpack-da@firefox.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd 4872025 source/extensions/langpack-da@firefox.mozilla.org/chrome/da/locale/da/global/datetimepicker.dtd
As those files' contents in source dir differs, The backup destination files got overwritten on each rsync run, because one of the targets always differs. So the directory layout is causing your problems. Was the backup created solely by rsync? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c3 --- Comment #3 from Peter van Hoof <pvh@oma.be> 2012-11-05 09:16:22 UTC --- With the test case I do not get the warnings either, but it clearly shows problems. I am pretty certain these problems are at the root of the warnings / error messages as well, but I do not know why they do not show up in the test case. Maybe you need a more elaborate test case for that, or maybe it is because I created the test case after the first problematic run... The backup directory was solely created by rsync with the command line arguments shown above. No changes were made either manually or by other software. The source directory was rsynced from the actual installation into an empty directory. I had the backup running for some time on a nightly schedule. Then the Mozilla rpms on the source machine got updated and the next backup caused the problems shown above. The backup directory was then rsynced after that problematic run, also into an empty directory. But anyway, I do not think that it is important whether there were changes made in the backup or not. Rsync should be able to create a valid mirror of the source regardless of what state the backup is in. After all, there is no telling what might have happened during the previous backup. Rsync should be able to recover even from things like power failures during a previous backup... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c4 --- Comment #4 from Vitezslav Cizek <vcizek@suse.com> 2012-11-09 11:24:08 CET --- rsync can't handle a situation, where two files which were previously hardlinked are later changed in a way that each one becomes a separate file. Example: # echo "a" > a # ln a b # rsync # rm b # echo "b" > b # rsync -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c5 --- Comment #5 from Vitezslav Cizek <vcizek@suse.com> 2012-11-14 00:24:21 CET --- Essentially, the --inplace option is broken with links. It's even mentioned in the manpage: "Moreover, attempts to copy differing source files onto a multiply-linked destination file will result in a "tug of war" with the destination data changing back and forth" rsync will sync the directories correctly if you omit the --inplace option. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c6 --- Comment #6 from Peter van Hoof <pvh@oma.be> 2012-11-14 10:37:01 UTC --- I found out that it works with --inplace omitted. That is what I am doing now. However, using --inplace is recommended practice for cow filesystems like Btrfs since it makes snapshotting more efficient in terms of using disk space (think of daily appending a few more mails to a huge inbox). Since cow filesystems seem to have a bright future, I think that this should be fixed, rather than just mentioning in the documentation that the --inplace option is broken with links. Obviously I am not the only one missing this point, see e.g. here: http://www.sanitarium.net/golug/rsync+btrfs_backups_2011.html This guy also advertises the combination of --hard-links and --inplace. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c7 --- Comment #7 from Vitezslav Cizek <vcizek@suse.com> 2012-11-19 16:49:49 CET --- I suggest you report this to upstream bug tracker: http://rsync.samba.org/bugzilla.html -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=785445 https://bugzilla.novell.com/show_bug.cgi?id=785445#c8 Vitezslav Cizek <vcizek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |UPSTREAM --- Comment #8 from Vitezslav Cizek <vcizek@suse.com> 2013-05-03 14:36:44 CEST --- This should be handled upstream. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com