When i download code via drush i get rsync error

sounds like we just introduced a bug with new rsync option. greg?

This looks like a duplicate of #955092: drush support for rsync version lower than 2.6.9, but I don't see how dl relates to that issue; as far as I know, only sql-sync uses --remove-source-files. I'll have to investigate.

This is what I get:

$ drush dl tao
Project tao (6.x-3.2) downloaded to /home/ga/local/drush/tao.

If #0 was confused and was actually using sql-sync, then everything makes sense, and this is a duplicate. I don't see how dl can be throwing this error.

My test above is invalid; clearly I need to test on a system running rsync protocol 29. My guess is that jonhattan switched the dl code to use rsync rather than rename to fix the cross-volume bug. If that's the case, then this can be fixed by committing #955092: drush support for rsync version lower than 2.6.9 and adding $options['protocol'] = 29; in drushrc.php.

drush dl calls drush_move_dir() that try rename() and if it fail, silently calls rsync.

@yingtho: could you test to see if the advice in #4 clears up the problem for you? I only have one system using rsync protocol 29, and it only has one volume.

An alternative could be use mv instead of rsync in drush_move_dir(), I guess.

Does mv have the same cross-volume problem as rename on old versions of *nix? It works on my recent Ubuntu distribution.

Here (debian v4 / PHP v5.2.0-8+etch16 and linuxmint v7 / PHP v5.2.6-3ubuntu4.5) the rename alternative of drush_move_dir() never works.
In addition, on debian, the rsync alternative does not take place since drush_op ('mkdir', $dest) (see below) returns FALSE due to the fact that rename() creates a regular file in $dest (probably PHP's version is involved in this unwanted behavior).

-  // If rename works, then we're done.
-  if (@drush_op('rename', $src, $dest)) {
+  // If mv works, then we're done.
+  $exec = 'mv ' . $src . ' ' . dirname($dest);
+  $mv_result = drush_op('system', $exec);
+  if ($mv_result !== FALSE) {
     return TRUE;
   }
   // Bail if we can't make a directory at the
   // destination (e.g. permissions)
   if (!is_dir($dest) && (drush_op('mkdir', $dest) === FALSE)) {
     return FALSE;
   }
-  // If rename doesn't work, then try rsync.
+  // If mv doesn't work, then try rsync.
   $exec = 'rsync -raz --remove-source-files ' . $src . DIRECTORY_SEPARATOR . ' ' . $dest;
   $rsync_result = drush_op('system', $exec);
   if($rsync_result !== FALSE) {
     // --remove-source-files deletes all of the files, but
     // we still need to get rid of the directories.
     drush_op('drush_delete_dir', $src);
     return TRUE;
   }
   return FALSE;
 }

Applying the patch of above I do not have the problem (no more rename()) and the alternative rsync is not necessary (which does not mean it should be removed).

Are you proposing #9 as a patch to be tested?

If I understand correctly, then on Linux, the 'mv' should always work, and you will go no farther in the code. In Windows, the 'mv' will always fail, but the 'rename' will almost always work (since on Windows, you'll probably be moving from somewhere on C: to somewhere on C: most of the time). If the 'rename' does not work on Windows, then the 'rsync' will also fail (unless you are running under cygwin, in which case the 'mv' would have worked).

Is that about right?

Windows... I have a tendency to forget that it exists.

More than a proposal to test, my previous comment is what I have to do after a git pull, i.e., whenever I need to use the HEAD version on my debian distro.
In other words, is the description of an unwanted behavior to consider when proposing a solution to this issue, I think.

I don't understand #11. Do you mean that you apply the changes in #9 to drush-HEAD every time you update? If that's correct, then perhaps you should attach a patch and set the status to 'needs review'.

If I read #11 another way, though, you are saying that #9 is not a complete fix. Is that just because there is one known system (i.e. Windows) that can fails for all three attempts to move the directory?

#9 is a personal fix for the behavior than I described in the same comment. I will create a new issue for this tomorrow. Sorry if my English was/is not appropriate.

I'm not clear on whats oustanding. Is it a dupe of the rsync issue?

#9 is a suggestion for improving a different fix; it could go in a new issue later. Per #6, we're waiting for the OP to confirm this is a dupe; I presume it is. Setting status to 'needs more info'.

For reference, #9 is related to this another issue: #968948: Drush returns an error on dl command on subdomain named subsites.domain.com.

at present drush_move_dir() try rename and if it fails it does an invincible copy & delete.