I was running
drush sql-sync @oldsite @newsite

This is technically not a drush problem but is a problem that occurs when using drush, so I'm DOCUMENTING it here for reference or if anyone is game to fix this unlikely issue.

Using the latest greatest drush to assist migration from an old server.
The server is being abandoned because upgrading and things is not going to happen there, we've got a better destination host.
BUT that is why some of the tools on the target are old.
In this case, it appears that rsync --remove-source-files is not a valid command.
Over there:

rsync --version
rsync  version 2.6.6  protocol version 29

Over here:

rsync --version
rsync  version 3.0.4  protocol version 30

From looking at man rsync on the old machine, this opt just doesn't exist - as the error message implies.
Upgrading is not an option over there. Boo.

Work-around

By running with verbose debugging

drush -v -d sql-sync @oldsite @newsite

I could see the command that was supposed to run:

system(rsync -e 'ssh ' -azv --exclude="*.svn*" --exclude="settings.php" --exclude="robots.txt" --exclude=".htaccess" --stats --progress --remove-source-files username@host:/tmp/web81_db1.sql.qMnHtk /tmp/localsite.sql.094pGT)

And copied it, removed the troublesome --remove-source-files and ran the new command by hand. Also the next (failed) database import command that failed.

mysql  -v -hlocalhost -uusername -ppassword dbname   < /tmp/localsite.sql.094pGT

Work-around exists, no action needed really, but added here as an issue as a documentation hint for searchers. (throwing straight into "won't fix" unless anyone has a better idea"

Comments

corbacho’s picture

Hi, I ran into the same problem than you. (I am using version 3.3)

I look into the code of /drush/commands/sql/sync.sql.inc

if (!isset($source_dump)) {
      $source_dump = drush_sql_dump_file($source_db_url);
      $source_is_tmp = TRUE;
      $source_rsync_options['remove-source-files'] = TRUE;
    }

I understand from this that if you don't set the path alias for dump in your aliases, it will use the remove-source-files option in the rsync command.

So the fix is quite simple, add '%dump' in your alias file:

$aliases['mysite'] = array (
 (...)
  'path-aliases' => array(      
      '%dump' => '/home/... /temporal-sql-sync.sql',
   ),

Notice that is not a directory path, it has to be a concrete file .

If someone else can confirm it and marked it as *solved*, because I was trying different work-arounds at the same time but I think is this what solved the problem.

ericrdb’s picture

Status: Closed (won't fix) » Closed (fixed)

Thanks for documenting, I had this same issue and your solution worked great.

john franklin’s picture

Priority: Minor » Normal
Status: Closed (fixed) » Active

I consider this a bug. Drush needs to be smart enough to handle old versions of rsync that are still commonly found in the wild. RHEL 5 and CentOS 5.5 still use rsync 2.6.8.

moshe weitzman’s picture

Status: Active » Closed (won't fix)
pedroalb’s picture

Hi guys,

just use --rsync-version=x.x.x in your sql-sync command.

cheers.

Tristan Mugford’s picture

Great tip, thanks. Just for further information, I personally was able to fix this by setting just %dump-dir, as opposed to %dump.

Incidentally, I did try using --rsync-version as suggested in a later comment, but it wasn't recognised as a valid option.

I'm using Drush 5.1 on both machines, and rsync 3.0.8 and 2.6.8 on local and remote machines respectively.

zach harkey’s picture

Just wanted to leave a note that this thread really helped me figure out the nature of this problem. Strangely in my case, %dump-dir did not work but %dump did. In fact, I ended up setting both %dump and %dump-dir in my alias and my remote server started playing nice.