Problème IIS avec Drupal - Gestionnaire de mise à jour: échec de la mise à jour! Les répertoires sont verrouillés par php-cgi.exe

J'ai un problème lors de l'utilisation du "Gestionnaire de mise à jour" sur l'interface graphique. Certains répertoires sont verrouillés php-cgi.exeet le remplacement des répertoires d'origine par les nouveaux téléchargés (qui sont plus récents) échoue.
Mais je dois dire que ce n'est pas un problème d'autorisation, car les modules peuvent s'installés via « Installer à partir d' une URL » sur /admin/modules/install, et le travail sans problème.

Prenons un exemple:

1. Page des mises à jour disponibles ( /admin/reports/updates/update):

   

   Maintenant, je vérifie le module Select (ou autre) à mettre à jour ( peu importe le module que je choisis , les résultats sont les mêmes !! c'est donc juste un exemple).

2. J'ai cliqué sur le bouton "Télécharger ces mises à jour" .

3. OK, l'instance mise à jour du module est téléchargée sans problème:
   " Mises à jour téléchargées avec succès ":
4. Maintenant, je clique sur Continuer .
5. Voici l'erreur. Le résultat:
   "La mise à jour a échoué! Consultez le journal ci-dessous pour plus d'informations.
   Select_or_other
   • Erreur d'installation / mise à jour
   • Échec du transfert de fichiers, raison: impossible de copier D:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txtvers /Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt. "
6. OK, je commence à essayer d'inspecter les raisons possibles.
   • Voici ce que ma structure de répertoire Drupal ressemble à : . J'ai défini ../tmppour être le répertoire temporaire (en /admin/config/media/file-system), les fichiers Drupal sont dedans htdocs. C'est correct, car je peux installer des modules via l'interface graphique, comme je l'ai mentionné ci-dessus.
   • Lorsque j'essaie d'entrer dans le htdocs/sites/all/modules/select_or_otherrépertoire, je ne peux pas, car j'obtiens un "Accès refusé dans le fichier ......sites/all/modules/select_or_other!" lors de l' ouverture de Total Commander, et «n'est...sites/all/modules/select_or_other pas accessible L' accès est refusé. » lors de l' ouverture dans l' Explorateur Windows: ,
   • OK, je clique avec le bouton droit sur le dossier et ouvre Unlocker via son assistant dans le menu contextuel. Il dit que ce répertoire est verrouillé par php-cgi.exe: je clique sur "Tout déverrouiller", et le dossier peut maintenant être supprimé de lui-même (car il n'est plus verrouillé par php-cgi.exe), donc il suffit
   • Je peux trouver le répertoire du module select_or_other mis à jour dans tmp:
   • donc je dois le déplacer manuellement dans le sites/all/modulesrépertoire.

Quelles peuvent être les raisons possibles du blocage du répertoire par php-cgi.exe? (Peut-être que Windows Cache Extension 1.1 pour PHP 5.3 est installé via Web Platform Installer? Mais si oui, pourquoi est-ce que par exemple la suppression d'images ou similaire via l'interface graphique fonctionne correctement?)
Que puis-je faire pour éviter ce problème et laisser "Mettre à jour" gestionnaire "travail?

ce n'est pas sécurisé qui permet d'écrire des fichiers à partir de l'interface utilisateur Drupal pour la mise à jour des modules, au lieu d'utiliser ftp.

mais si vous le souhaitez, accédez au panneau plesk d'hébergement, explorez le répertoire httpdocs, cliquez avec le bouton droit de la souris, puis avec la permission, maintenant avec la permission, donnez la permission d'écriture à l'utilisateur du pool d'applications,

Merci

La raison pour laquelle php-cgi a le verrou est à cause de la façon "particulière" dont Windows gère l'accès aux fichiers et php / iis gère la "mise en cache". Fondamentalement, vous venez de créer le répertoire et avez essayé d'y accéder, mais le handle qui l'a créé n'a pas été libéré (il était donc toujours verrouillé). Ce n'est pas un problème drupal, c'est un problème IIS / PHP Et il n'y a pas de solution connue que je puisse trouver.

Fondamentalement, le conseil de base de ne pas utiliser IIS est le meilleur, j'ai vu ce problème dans plus que simplement Drupal avec IIS que j'ai résolu en passant à apache HTTPD (sur win32). Rappelez-vous que c'était pour la rentrée, avec un projet où je devais utiliser Windows 2000.

la meilleure façon que je connaisse d'exécuter Drupal sur Windows est via Apache (à cause de la gestion interne de PHP).

Quelques idées pour creuser dans la bonne direction:

Si vous rencontrez le même problème avec Drush, je ne suis pas sûr que ce soit un problème IIS. Drush n'exécute-t-il pas simplement PHP à partir de la ligne de commande sans IIS? Vous pouvez essayer cela en arrêtant IIS (iisreset / stop) puis en exécutant la commande de mise à jour Drush et je m'attendrais à ce que vous obteniez le même résultat.

L'autre chose (désolé, je n'ai pas assez de réputation pour commenter directement la réponse de Lawri):

"Fondamentalement, vous venez de créer le répertoire et avez essayé d'y accéder, mais le handle qui l'a créé n'a pas été libéré"

Est-ce vraiment vrai? D'après l'article d'origine, il semble qu'il ait créé le dossier dans "tmp", mais le verrou se trouve sur le dossier déjà existant dans "httpdocs".

Je suppose que php-cgi essaie de copier de tmp vers httpdocs, échoue pour une raison et ne supprime pas le verrou. Donc, lorsque vous étudiez après l'échec, vous voyez un verrou sur httpdocs, mais je pense que la raison initiale de l'échec n'est pas un verrou, il peut s'agir d'un problème d'autorisation sur le dossier tmp après tout!