pm update for a module already in sites/all/modules

I am trying to replicate this in preparation for exploring a fix

Noticed this myself - I think overwriting (rather than moving out of the way) is probably fine behavior, since our filenames are pretty unique.

I was actually thinking that for proper behaviour we should download the tar.gz files to /tmp (or an optional user provided temp directory), and then use the -C parameter to tar to extract them to the correct directory base, rather than using the parent directory for the tarball scratch space.

The short term fix must be to backup the offending file since it is external to drush and we would have no idea whether it contains valuable data.

This is actually kind of an edge case because only development releases of projects have the same file name across multiple versions. Under production use, this kind of naming collision would not happen during an update; by definition the update version would have a different file name.

For the long term, I was also thinking along the same lines too. We would have to be careful with a shared location due to concurrent users... I would expect that a unique drush session identifier would need to be generated and used as a directory name under the download temporary area to avoid further headaches with respect to naming collisions.

Well, I replicated this issue in the DRUPAL-6--1-2 release tag and also found that it has already been fixed in the DRUPAL-6--1 branch head. It simply overwrites the offending file at this time.

we have unpublished all releases for the moment. use head. for drush_extras, use the tip for the version of drupal you need. drush_extras is soon being folded back into drush, fyi.