Bug 1414070 - 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 7
Classification: Red Hat
Component: rsync
Version: 7.3
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Michal Ruprich 🐧
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-17 16:43 UTC by Pat Riehecky
Modified: 2019-12-09 08:50 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1717119 (view as bug list)
Environment:
Last Closed: 2019-12-06 16:06:38 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Pat Riehecky 2017-01-17 16:43:16 UTC
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 3 Tomáš Hozza 2019-12-06 16:06:31 UTC
Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug.

For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/

Comment 4 RHEL Program Management 2019-12-06 16:06:38 UTC
Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto

Comment 5 Pat Riehecky 2019-12-06 16:11:52 UTC
Can we move this bug to RHEL8?

Comment 6 Tomáš Hozza 2019-12-09 08:50:19 UTC
(In reply to Pat Riehecky from comment #5)
> Can we move this bug to RHEL8?

It has been cloned as comment #3 stated - https://bugzilla.redhat.com/show_bug.cgi?id=1717119


Note You need to log in before you can comment on or make changes to this bug.