Bug 787032 - rsync overwrites symbolic link on destination regardless of newer timestamp
Summary: rsync overwrites symbolic link on destination regardless of newer timestamp
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rsync
Version: 5.7
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Michal Luscon
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 798457
TreeView+ depends on / blocked
 
Reported: 2012-02-02 23:53 UTC by Kevin Toyama
Modified: 2018-11-28 21:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-29 09:26:51 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Kevin Toyama 2012-02-02 23:53:30 UTC
Description of problem:
rsync is being performed between 2 servers.  The source server has a symbolic link in it, link1, to a directory, dir1.  The destination server has a symbolic link, link1, pointing to a directory, dir2.   The destination symbolic link, link1, and directory, dir2, both have newer timestamps than on the source system.

rsync is run using the -rluv options and the source will always overwrite the destination.  The destination should not be overwritten since it's timestamp is newer.

Version-Release number of selected component (if applicable):
rsync-3.0.6-4.el5_7.1

How reproducible:
always.

Steps to Reproduce:
* Server A
[user1@localhost ~]$ rpm -qa rsync
rsync-3.0.6-4.el5_7.1
[user1@localhost rs_test]$ ll
total 20
drwxrwxr-x 2 user1 user1 4096 Dec 19 08:46 dir1
drwxrwxr-x 2 user1 user1 4096 Dec 19 08:24 dir2
lrwxrwxrwx 1 user1 user1    4 Dec 19 08:52 l -> dir1

[user1@localhost rs_test]$ rsync -rluv /tmp/rs_test/ 192.168.122.38:/tmp/rs_test
user1.122.38's password:  
sending incremental file list
l -> dir1
dir1/file1

sent 147 bytes  received 36 bytes  73.20 bytes/sec
total size is 6  speedup is 0.03


* Server B
[user1@localhost rs_test]$ rpm -qa rsync
rsync-3.0.6-4.el5_7.1
[user1@localhost rs_test]$ ll
total 20
drwxrwxr-x 2 user1 user1 4096 Dec 19 09:09 dir1
drwxrwxr-x 2 user1 user1 4096 Dec 19 08:24 dir2
lrwxrwxrwx 1 user1 user1    4 Dec 19 09:21 l -> dir2

- after rsync -

[user1@localhost rs_test]$ ll
total 20
drwxrwxr-x 2 user1 user1 4096 Dec 19 09:22 dir1
drwxrwxr-x 2 user1 user1 4096 Dec 19 08:24 dir2
lrwxrwxrwx 1 user1 user1    4 Dec 19 09:22 l -> dir1  <- same behavior as before

  
Actual results:
link on destination is always overwritten with the source symbolic link.

Expected results:
link on destination should not be overwritten if it has a newer timestamp than on the source.

Additional info:
Tested on RHEL5.7, RHEL6.2, and Fedora 16.  All exhibit the same behavior.

Comment 4 Michal Luscon 2012-03-29 09:26:51 UTC
Rsync man page:

-u, --update
    This forces rsync to skip any files which exist on the destination and have a modified time that is newer than the source file. (If an existing destination file has a modification time equal to the source file's, it will be updated if the sizes are different.)

    Note that this does not affect the copying of symlinks or other special files. Also, a difference of file format between the sender and receiver is always considered to be important enough for an update, no matter what date is on the objects. In other words, if the source has a directory where the destination has a file, the transfer would occur regardless of the timestamps.

    This option is a transfer rule, not an exclude, so it doesn't affect the data that goes into the file-lists, and thus it doesn't affect deletions. It just limits the files that the receiver requests to be transferred. 

Thus I am closing this as a notabug.

Comment 5 Louis van Dyk 2015-04-02 14:08:48 UTC
The -K / --keep-dirlinks rsync option would make it behave in the desired way.

I also needed this info, so updating here to help anyone else needing this.


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