Bug 829916

Summary: Avoid a dry-run error trying to stat a prior hardlink
Product: Red Hat Enterprise Linux 6 Reporter: Renato Botelho do Couto <rbcouto>
Component: rsyncAssignee: Luboš Uhliarik <luhliari>
Status: CLOSED INSUFFICIENT_DATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2CC: dapospis, ebenes, rbcouto, thozza
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-16 13:46:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Renato Botelho do Couto 2012-06-07 19:48:58 UTC
Description of problem:
When you run rsync with --dry-run and -H parameters, and there are hardlinks on the server side, it tries to stat the hardlink that doesn't exist yet.

Version-Release number of selected component (if applicable):
rsync-3.0.6-5.el6_0.1.ppc64

How reproducible:
Always

Steps to Reproduce:
1.A server with hardlinks
2.rsync -H --dry-run
3.
  
Actual results:
Errors like this:
rsync: stat "/path/file" failed: No such file or directory (2)

Expected results:
No errors

Additional info:
This bug was fixed on rsync 3.0.7, at the following commit:

http://gitweb.samba.org/?p=rsync.git;a=commit;h=b15fa9bd7bf3a379ab03eead92701cff42cdaa13

Comment 2 RHEL Program Management 2012-09-07 05:09:29 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 3 Martin Žember 2014-06-25 15:55:46 UTC
How is it possible to reproduce the bug?

I have tried these commands:

cd /tmp
mkdir s/ t/
touch s/lala
ln s/lala s/hard
rsync --rsh=ssh -avz -H --dry-run s/ localhost:/tmp/t/

I have also tried with more hardlinks pointing to the same file and transferring in the opposite direction (from the server) and with none/some/all of the files present in the target directory.

The output usually looks like this:
$ rsync --rsh=ssh -avH --dry-run s/ localhost:/tmp/t/
sending incremental file list
./
lala
hard => lala

sent 70 bytes  received 30 bytes  200.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

My version is (I guess the architecture is not important here):
rsync-3.0.6-5.el6_0.1.x86_64

I use the same machine as a server and as a client, but connecting through ssh.

Comment 5 Martin Žember 2014-07-01 16:28:06 UTC
I have tried the commands and some of the mentioned scenarios from the comment #3 on the same architecture as the reporter has, but without any success (no errors).

Version:
rsync-3.0.6-5.el6_0.1.ppc64

Comment 7 Tomáš Hozza 2016-08-16 13:46:37 UTC
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

As this bug has been in NEEDINFO for an extended period of time we are going
to close this bug due to inactivity. If you would like to pursue this
matter feel free to reopen this bug and attach the needed information.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical
defects.

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux.

Comment 8 Red Hat Bugzilla 2023-09-14 01:29:46 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days