rsync of symbolic links bug

Tom Schmidt tschmidt at micron.com
Tue May 13 01:46:36 EST 2003


jw schultz wrote:
> On Fri, May 09, 2003 at 12:58:46PM -0700, Wayne Davison wrote:
> 
>>On Thu, May 08, 2003 at 09:44:10AM -0600, Tom Schmidt wrote:
>>
>>>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.
>>
>>Yes, that's one possible solution.  However, changing the sort order
>>would add an incompatibility with older versions, so I'm wondering if a
>>different change wouldn't be better.  I think it would be possible to
>>change the loop in the generate_files() function to exclude symlinks,
>>and then loop over the list again to process them all last.  Since the
>>sender doesn't care if the list is processed in order, I think that this
>>would allow an updated receiving side to interoperate with older sending
>>side and still benefit from the revised fetch order.
>>
>>The downside would be that if rsync is processing a really large file
>>list, it may run noticably slower if it has to traverse the list twice
>>instead of once.  So, it would be good to measure this and see what kind
>>of a performance hit we're talking about.
> 
> 
> Make that thrice.  If you are avoiding making links unsafe
> you will want to do file deletion after the link creation so
> this would be tied to --delete-after.
> 
> Of course --delete-after could well be all he needs to avoid
> his problem.

The --delete-after option does not address this issue.  rsync still
updates the symbolic link to point to the new file before the file it
is point to is rsynced.  To fix this, rsync needs a new --symlink-after
type of option that causes it to update symbolic links after updating
files and directorires to prevent the race-condition of a symbolic link
being updated that points to a non-existant file until that file is
rsynced later in it alphabetical file sort routine.

Isn't anyone else seeing this problem with using rsync to update live
mirrors of filesystems?

Tom
-- 
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 micron.com  http://www.4schmidts.com/



More information about the rsync mailing list