0

I have a Drupal site running on localhost (Windows) that I'm trying to update from 8.6.7 to 8.6.15.

When using Drush to perform the update (drush up drupal -y), I encounter the following error:

Unable to copy C:\Users\USERNA~2\AppData\Local\Temp/drush_tmp_1556533742_5cc6d1ee1cacf/drupal-8.6.15 to
W:\htdocs\site-name\www/drupal-8.6.15.
Unable to move C:\Users\USERNA~2\AppData\Local\Temp/drush_tmp_1556533742_5cc6d1ee1cacf/drupal-8.6.15 to
W:\htdocs\site-name\www/drupal-8.6.15.
Updating project drupal failed. Attempting to roll back to previously installed version.
Backups were restored successfully.

I've tried:

  • clearing Drush's cache (drush cc drush)
  • updating Drush (via composer) (now running Drush 8.2.3)
  • clearing Drupal's caches

But the problem remains.

This problem does NOT occur when updating modules. Only Drupal itself.

I checked the C:\Users\USERNA~2\AppData\Local\Temp folder while drush was working, and I was able to confirm that the drush_tmp_1556533742_5cc6d1ee1cacf subfolder was indeed present for a time (containing the Drupal .tar.gz and its upacked folder). So there's no issue in writing in this folder.

Any idea what causes this and how to solve it?

Thanks in advance.

|improve this question

closed as too broad by kiamlaluno♦ May 12 at 11:33

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

1

We can only guess at an answer. A likely scenario might be disk space, permissions, or some other conflict with Drush & filesystem, but that's speculation.

Run the same command with the --debug flag (drush up drupal -y --debug) to see a verbose dump of what Drush is doing and look for errors/warnings that occur as Drush is attempting a core update. Once you know the underlying filesystem issue you'll be able to resolve it.

|improve this answer
  • Thanks for the --debug tip. I've upgraded my sites manually for now, so I can't try it at the moment, but I'll keep that in mind for the next update. (No disk space issue (18GB free), and as stated drush is able to create the "temp" subfolder, unpack the D8 files and then delete everything, so I don't think it's a permission issue.) – s427 Apr 30 at 9:59
0

Please upgrade to Drush 9 and try again. See Drush's Drupal Compatibility.

enter image description here

And then maybe use grasmash/composerize-drupal to composerize your Drupal installation because:

enter image description here

|improve this answer
  • Thanks for the info, but I also have some D7 sites that I need to manage, so I'd rather stay with Drush 8. The pace at which everything changes around Drupal nowadays is a bit discouraging at times... :/ – s427 Apr 30 at 10:07
  • @s427 – That shouldn't be the reason to stick to Drush 8. See drupal.stackexchange.com/questions/267511/… on how to have multiple Drush versions. Apart from that in the composerized Drupal you'll use the local Drush. $ cd /my/drupalproject/web && ../vendor/bin/drush cr and not the globally installed Drush. – leymannx Apr 30 at 10:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.