RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1717119 - rsync -H option yields corrupt replicas (due to non-unique inode ids)
Summary: rsync -H option yields corrupt replicas (due to non-unique inode ids)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: rsync
Version: 8.0
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: 8.0
Assignee: Michal Ruprich
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-04 17:56 UTC by Pat Riehecky
Modified: 2021-02-01 07:41 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1414070
Environment:
Last Closed: 2021-02-01 07:41:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Pat Riehecky 2019-06-04 17:56:44 UTC 
+++ This bug was initially created as a clone of Bug #1414070 +++

Description of problem:

When exporting multiple filesystems it is possible for rsync to incorrectly identify a file as having a hardlink to another entirely different file.

rsync is using the inode of a file as the only test to determine if two files are hardlinked.  However, it is possible for two files to have the same inode (because they are on different filesystems) but be exposed via a single rsync target.

Version-Release number of selected component (if applicable):rsync-3.0.9-17.el7


How reproducible:
Difficult to build reproduction case, but once created, works every time.


Steps to Reproduce (a):
1.Build two file systems (A and B), mount A on /srv/example/
2.Mount filesystem B on /srv/example/otherfs
3.Put a file in A with unique content and a known inode number
4.Put a different file in B with unique content the same inode number as the file in A
5.Have rsync server export /srv/example and all sub files and directories
6.Use the rsync server to sync down /srv/example with hardlink detection enabled (rsync -avH)
7.The files you've synced down should now be hardlinked, and thus the content of one file is incorrect.


Steps to Reproduce (b):
1.Build two file systems (A and B), mount A on /srv/example/
2.Mount filesystem B on /srv/example/otherfs
3.Put a file in A with unique content and a known inode number
4.Put a different file in B with unique content the same inode number as the file in A
5.Mount /srv/example via NFS3 on a system (NFS3 doesn't promise unique inodes) as /srv/nfsmounted
6.Have rsync server export /srv/nfsmounted and all sub files and directories
7.Use the rsync server to sync down /srv/nfsmounted with hardlink detection enabled (rsync -avH)
8.The files you've synced down should now be hardlinked, and thus the content of one file is incorrect.


Actual results:
Non identical files are treated as hardlinks and data is not transfered.

Expected results:
Only identical files treated as hardlinks.

Additional info:
If, in addition to checking the inode, rsync could check the file has the same number of bytes or has the same mtimestamp that should be sufficient to avoid the collision behavior.

Conversation on upstream email list:
https://www.mail-archive.com/rsync@lists.samba.org/msg29385.html
Comment 1 Tomáš Hozza 2020-03-27 13:54:13 UTC 
Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution.

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.

For information on how to contact the Red Hat production support team, please visit:
https://access.redhat.com/support
Comment 2 RHEL Program Management 2020-03-27 13:54:22 UTC 
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Comment 3 Pat Riehecky 2020-04-01 15:11:58 UTC 
I would like to appeal this decision as a number of NFS appliances follow the NFSv3 rules to not worry about unique inodes.
Comment 6 RHEL Program Management 2021-02-01 07:41:16 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.