rsync of symbolic links bug

[jw schultz]

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.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt