DO NOT REPLY [Bug 3422] dry run fails when encountering dangling symbolic link

bugzilla-daemon at dp3.samba.org bugzilla-daemon at dp3.samba.org
Thu Jan 19 03:38:18 GMT 2006


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





------- Comment #2 from hashproduct at verizon.net  2006-01-18 20:38 MST -------
Created an attachment (id=1702)
 --> (https://bugzilla.samba.org/attachment.cgi?id=1702&action=view)
Makes receiving rsync process deletions only in directories

I found the problem.  The receiving rsync performs deletions by scanning the
file list from the sender for directories.  For each directory the sender sent,
the receiver looks for something at the same path in the destination.  If the
receiver finds something, it assumes that something is a corresponding
directory and processes deletions inside it; if the receiver finds nothing, it
just moves on.

That assumption is OK most of the time.  If one runs Peter's second test case
without --dry-run, rsync deletes the symlink "link" on the grounds that it is
about to be replaced by a directory; when it goes to process deletions in the
directory "link" that the sender named, it finds nothing there on the
destination.  But with --dry-run, "link" gets fake-deleted from the receiver. 
delete_in_dir("link") is called, sees something by the name of "link",
incorrectly assumes it is a directory, and tries to process deletions.

That no error is produced when the symlink is valid is immaterial.  When rsync
is completely in link-aware mode (--links and not --keep-dirlinks), it should
treat symlinks simply as files of a special kind that contain strings; it
should never issue a system call that follows a symlink.

I wrote a very simple patch that makes delete_in_dir try to delete only in
directories.  That fixes the problem, but I don't know if it's the right way to
fix the problem.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list