rsync of symbolic links bug

Tom Schmidt tschmidt at
Sat May 10 03:46:44 EST 2003

jw schultz wrote:
> On Thu, May 08, 2003 at 09:44:10AM -0600, Tom Schmidt wrote:
>>I am seeing a problem with the way the rsync of symbolic links
>>is done.  Here is a simple example to duplicate this issue:
> [snip]
>>ACK!  The symbolically linked file pointing to foo/file4 got
>>updated first, causing anyone using it to see it pointing at a
>>non-existant file!
>>This bug is essentially a race condition that can cause
>>the mirrored system to see the symbolic link get updated to
>>point to a non-existant file since the file it is pointing
>>at has not been mirrored yet.
> Not a bug, it is a race condition.  rsync is not atomic.

Yes, but this race condition can be fixed by pushing the symbolic
link updates after any file and directory updates like I stated
below.  I have not looked at the rsync code to see how to change


>>The fix for this would be to have rsync internally sort its filelist
>>to push the updated files and directories first, then the updated
>>symbolic links last.  How can this be done?  Or am I missing
>>some rsync commandline issue to fix this problem?
>>My only workaround at this point is to rsync twice, the first time
>>without pushing any symbolic links, but this workaround can
>>still burn us if an update is made to the master copy between
>>the two rsync runs.
> If you need atomic updates use a staging area.  Have two
> directories.  rsync to the unused one and then swap them.
> --copy-links might also be of use.

This actually gives flakier results!  Attached is my test script,
and sometimes my copied link gets updates, sometimes it doesn't!
But using --copy-links won't fix my problem of trying to mirror
a filesystem since I don't want the mirror to get copies of the
file instead of symbolic links since that would inflate the size
of the mirrored filesystem.  I need rsync to be able to do a
better live update of mirrored filesystems.

If rsync cannot be updated to mirror the symbolic links after
mirroring files and directories by default, then at least this
feature needs to be available by a commandline option to address
this issue.  Doesn't anyone else see this race condition?

Tom L. Schmidt, Manager/SysAdmin Characterization Equipment
Micron Technology, Inc.
8000 S. Federal Way  P.O. Box 6  Mail Stop 376  Boise, Idaho USA  83707-0006
mailto:tschmidt at
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/x-sh
Size: 406 bytes
Desc: not available
Url :

More information about the rsync mailing list