Bug 1673 - Verbose dry run doesn't report replacements of symlink with directory
Verbose dry run doesn't report replacements of symlink with directory
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.3
All Linux
: P5 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-27 23:18 UTC by John Van Essen
Modified: 2005-04-01 11:22 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Van Essen 2004-08-27 23:18:29 UTC
After an rsync, if a directory on the target is replaced by a symlink pointing
to a new location containing the original, unchanged, directory content, a
verbose dry-run will *not* report that the directory contents from the source
will be transferred to the target and replace the symlink (which is what happens
during the non-dry-run invocation).

I discovered this during preliminary testing prior to using the new 2.6.3
--keep-dirlinks option (which, BTW, works just great in 2.6.3pre1).

This bug may be related to bug 1433.

The problem occurs with 2.6.2 (and possibly earlier) as well as with 2.6.3pre1.

Here's an example using 2.6.2:

$ ll -R a
a:
total 12
-rw-r--r--    1 jve      users          29 Feb  8  2004 f1
-rw-r--r--    1 jve      users          29 Feb  8  2004 f2
drwxr-xr-x    2 jve      users        4096 Feb  8  2004 projects

a/projects:
total 8
-rw-r--r--    1 jve      users          29 Feb  8  2004 p1
-rw-r--r--    1 jve      users          29 Feb  8  2004 p2
$ rm -rf a1
$ rsync -la a/ a1/
$ rm -r a1/projects
$ ln -s ../a/projects a1/projects
$ ll -R a1
a1:
total 8
-rw-r--r--    1 jve      users          29 Feb  8  2004 f1
-rw-r--r--    1 jve      users          29 Feb  8  2004 f2
lrwxrwxrwx    1 jve      users          13 Aug 28 02:10 projects -> ../a/projects
$ rsync -lavn a/ a1/
building file list ... done

wrote 146 bytes  read 20 bytes  332.00 bytes/sec
total size is 116  speedup is 0.70
$ rsync -lav a/ a1/
building file list ... done
./
projects/
projects/p1
projects/p2

wrote 292 bytes  read 60 bytes  704.00 bytes/sec
total size is 116  speedup is 0.33
Comment 1 Wayne Davison 2004-09-17 15:32:41 UTC
Yes, there are several aspects of a full transfer that aren't reported properly
in dry-run mode.  In this instance the symlink happens to point to a directory
where up-to-date files exist, so rsync is fooled into believing that they won't
be transferred.  To fix this, rsync will need to keep track of invalidated path
prefixes that cause files below them to be marked as not existing.  Something to
look into fixing at some point in the future, along with bug 1433 and bug 1764.
Comment 2 Wayne Davison 2005-02-12 14:37:31 UTC
This is now fixed in the CVS version.  It became very easy to fix after some
recent changes I made provided the hierarchical depth value for each file, which
means that anytime a directory is missing in --dry-run mode, we just need to
ignore all items that are deeper in the list up to the next item that is
less-than or equal-to the missing depth.

Note that there is a potential for the incorrect output to occur when talking to
an older rsync (prior to protocol 29).  This is because the sort algorithm in
earlier rsyncs might put an item from outside a directory's hierarchy in between
the directory and its contents.  To see this in action, update to the CVS
version (also available in the latest "nightly" tar file), add a file named
"projects.txt" in the "a" dir of the above test-case, and verify that the
--dry-run output works properly. Then, repeat the test with the debug option
"--protocol=28" and the items inside the projects dir will not be listed in
--dry-run mode (because projects.txt sorted in between the dir and its contents).