rsync - Oct 2014 - [Bug 10893] New: Allow option to sync symlinks last (or delayed)

https://bugzilla.samba.org/show_bug.cgi?id=10893

            Bug ID: 10893
           Summary: Allow option to sync symlinks last (or delayed)
           Product: rsync
           Version: 3.1.1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: moffatjd at gmail.com
        QA Contact: rsync-qa at samba.org

Presently rsync will create symlinks first (on the receiver side) and then it
will sync the content that is potentially being linked. This can cause race
conditions on the receiver side.

For example, given the small hierarchy already existing on the receiver side:

/foo -> foo_1.0
/foo_1.0

And then assume we have an updated hierarchy on the sender side:

/foo -> foo_2.0
/foo_1.0
/foo_2.0

When rsync updates the receiver side with the new foo_2.0, it first does the
symlink (pointing foo to foo_2.0) but the contents of foo_2.0 have not been
synced yet. During this time frame (when link is sycned, but content is not)
the symlink points to a non-existent directory. If a program on the receiver
side should reference foo during the rsync, it will fail.

The option --delay-updates does not fix this behavior, and is the closest
option available to obtaining this 'atomic' like behavior.

Please consider an option --link-after (similar to --delete-after) that simply
waits and does all symlinks after all updates.

OR

Please consider creating a --delay-links option that would not sync a link
until the content of the link (including subdirs) is complete. 


Thank you.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.