Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

I have some problem when using the "Update manager" on the GUI. 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.
BUT I have to mention that it's not a permission issue, because the modules can get installed via "Install from a URL" on /admin/modules/install, and work without a problem.

Let's take an example:

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

    Available updates

    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": 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." Update failed!
  6. OK, I'm starting to try to inspect the possible reasons.
    • Here's what my Drupal directory structure looks like: TC directory structure. 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: trying to open directory in Total Commander, trying to open directory 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: Unlocker - directory 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: updated module's directory in <code>tmp</code>
    • 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?

share|improve this question
    
I'm seeing exactly the same behaviour with Drupal 7.15 on IIS7/2008R2. It would be great to fix this. –  Nic Aug 14 '12 at 20:45
    
@Nic: I agree! :) –  Sk8erPeter Aug 14 '12 at 22:31
    
I've seen this intermittently. Out of curiosity does refreshing your app pool unlock as well? –  Brent Sep 11 '12 at 18:54
2  
I know it's off topic, but I have to say it - run away from Drupal on IIS. As I can see on the screenshots, you might be using it for local development. Check out WAMP or Acquia Dev Desktop. If you simply have to use it on a production server, ignore my comment :) I have to use IIS for certain sites and so far it hasn't been a good experience. –  Ivanhoe123 Sep 11 '12 at 19:17
    
@Brent: I don't know. After running a page in Drupal, the files and directories seem to get locked for an unknown period. By the way, I'm using Drush too, and when I want to update a module using drush up -y, I experience the same problem: I have to unlock these files and directories with Unlocker to make it work, otherwise I get the error message that these directories cannot be written/removed, and the update process gets interrupted. If I use Unlocker BEFORE running this process, the update is successful. –  Sk8erPeter Sep 11 '12 at 22:45

3 Answers 3

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

share|improve this answer

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).

share|improve this answer

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!

share|improve this answer
    
if that was the case he could also not move it 'by hand', the directory gets created as part of the upgrade process. IIS is involved through its CGI interface, that is known for causing weird errors. and the error reported is not the "can not access" but "can not copy to" error. –  LvB Jan 6 at 14:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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