Bug 3637 - Regression 2.6.6 to 2.6.7 when syncing with 2.6.6 on windows - --no-r
Regression 2.6.6 to 2.6.7 when syncing with 2.6.6 on windows - --no-r
Product: rsync
Classification: Unclassified
Component: core
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-03-28 12:32 UTC by Nathan Neulinger
Modified: 2006-04-22 12:00 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Neulinger 2006-03-28 12:32:01 UTC
Just tried updating a linux build of rsync from 2.6.6 to 2.6.7. A previous sync that worked fine against a 2.6.6 windows build now no longer functions. I get an error from the remote side saying --no-r: unknown option.

+ ./rsync -Wav --force --delete --delete-after --progress --stats --files-from=data/afs_umr.edu_dept_ua/files.clean.dat --from0 /afs/umr.edu/dept/ua/ umr-store3.cc.umr.edu::dept/ua/
building file list ... 
rsync: link_stat "/afs/umr.edu/dept/ua/SYNC-REPORT/AFS-ACLS.new.txt" failed: No such file or directory (2)
rsync: on remote machine: --no-r: unknown option
rsync error: requested action not supported (code 4) at /home/lapo/packaging/tmp/rsync-2.6.6/clientserver.c(517)
rsync: writefd_unbuffered failed to write 4092 bytes: phase "send_file_entry" [sender]: Connection reset by peer (104)
rsync: connection unexpectedly closed (4 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(471) [sender]
Comment 1 Wayne Davison 2006-03-28 12:55:24 UTC
This is not a regression, this is rsync preventing an incompatible set of options from causing a hang or a crash.  In older rsyncs, using --delete without -r would silently drop the --delete options.  Beginning with 2.6.7, rsync allows --delete to also be used when --dirs is in effect (which it is with --files-from), but it needs to ensure that the remote rsync is new enough to handle this combination, or the server might silently drop the --delete option, and the protocol could corrupt or hang (due to differences in the exchange of excludes when one side thinks that --delete is in effect and the other does not).

The 3 ways you can deal with this are:

1. Drop the --delete and --delete-after options (they were ignored before anyway).
2. Add the -r option (which will cause all directories referenced in the --files-from file to be recursively transferred).
3. Upgrade the remote rsync to 2.6.7.

It would have been nice to have generated a helpful error in this circumstance, but since older versions of rsync silently dropped the --delete option instead of generating an error that the delete option required --relative, I had to come up with a creative (and, unfortunately, cryptic) way to ensure that older versions rejected options that they could not handle properly.