Update fails because directories are locked by php-cgi.exe

Question

I have some problem when using the Update manager. Some directories get locked by php-cgi.exe, and thus the replacement of the original directories with the newly downloaded ones (which are fresher) is not successful.
It's not a permission issue, since modules can be installed via Install from a URL on /admin/modules/install, and that works without problems.

Let's take an example:

1. Available updates page (/admin/reports/updates/update):

   

   Now I check Select (or other) module to be updated (it doesn't matter which module I choose, the results are the same!! so it's just an example).

2. I hit "Download these updates" button.

3. OK, the module's updated instance gets downloaded without a problem:
   "Updates downloaded successfully":

4. Now I click on Continue.

5. Here comes the error. The result:
   "Update failed! See the log below for more information.
   select_or_other

   • Error installing / updating
   • File Transfer failed, reason: Cannot copy D:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txt to /Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt."

6. OK, I'm starting to try to inspect the possible reasons.

   • Here's what my Drupal directory structure looks like: . I set ../tmp to be the temporary directory (in /admin/config/media/file-system), the Drupal files are in htdocs. This is correct, as I can install modules via the GUI, as I mentioned above.
   • When I try to enter the htdocs/sites/all/modules/select_or_other directory, I can't, because I get an "Access denied on file ......sites/all/modules/select_or_other!" when opening in Total Commander, and "...sites/all/modules/select_or_other is not accessible. Access is denied" when opening in Windows Explorer: ,
   • OK, I right click the folder, and open Unlocker via its assistant in the context menu. It says this directory is locked by php-cgi.exe: I click on "Unlock All", and the folder can now get deleted of itself (as it's not locked anymore by php-cgi.exe), so it simply
   • I can find the updated select_or_other module's directory in tmp:
   • so I have to manually move it to sites/all/modules directory.

What can be the possible reasons of the lockup of the directory by php-cgi.exe? (Maybe Windows Cache Extension 1.1 for PHP 5.3 installed via Web Platform Installer? But if yes, why is that for example the deletion of images or similar via the GUI works correctly?)
What can I do to avoid this problem, and let "Update manager" work?

Answer 1

The reason for php-cgi for having the Lock is because of the "peculiar" way windows handles file access, and php/iis handles "caching". Basically you just created the directory and tried to access it, but the handle that created it was not released (so it was still locked). This is not a drupal issue, its an IIS/PHP issue And there is no known workaround that I could find.

Basicly, do the base advise of not using IIS is the best, I have seen this problem in more than just drupal with IIS that I solved by moving to apache HTTPD (on win32). Mind you that was for back at school, with a project where I was required to use windows 2000.

the best way I know of running drupal on windows is through apache (because of the internal handling of php).

Answer 2

this is not secure that allow to write file from Drupal user interface for updating modules, instead of this use ftp.

but if you want then go to plesk panel of hosting explore httpdocs directory right click and then on permission, now in permission give write permission to Application pool user,

Thanks

Answer 3

Some ideas to dig in the right direction:

If you have the same problem from Drush, then I am not sure if this is an IIS problem. Is Drush not just executing PHP from the command line without IIS? You can try this by stopping IIS (iisreset /stop) and then running the Drush update command and I would expect you to get the same result.

The other thing (sorry, I don't have enough reputation to directly comment on Lawri's answer):

"Basically you just created the directory and tried to access it, but the handle that created it was not released"

Is this really true? From the the original post it looks like he created the folder in "tmp", but the lock is on the already existing folder in "httpdocs".

My guess is that php-cgi tries to copy from tmp to httpdocs, fails for a reason and doesn't remove the lock. So when you investigate after the failure, you see a lock on httpdocs, but I think the initial reason for failing is not a lock, it might be a permission issue on the tmp folder after all!