Problema no IIS com o Drupal - Gerenciador de atualizações: atualização falhada! Diretórios são bloqueados pelo php-cgi.exe

Estou com algum problema ao usar o "Gerenciador de atualizações" na GUI. Alguns diretórios ficam bloqueados php-cgi.exee, portanto, a substituição dos diretórios originais pelos diretórios baixados recentemente (que são mais atualizados) não é bem-sucedida.
Mas eu tenho que mencionar que não é um problema de permissão, porque os módulos podem ser instalado via "Instalar de uma URL" na /admin/modules/install, e trabalhar sem um problema.

Vamos dar um exemplo:

1. Página de atualizações disponíveis ( /admin/reports/updates/update):

   

   Agora eu verifico o módulo Select (ou outro) a ser atualizado ( não importa qual módulo eu escolher , os resultados são os mesmos !! então é apenas um exemplo).

2. Eu bati "Baixar essas atualizações" botão.

3. OK, a instância atualizada do módulo é baixada sem problemas:
   " Atualizações baixadas com sucesso ":
4. Agora clico em Continuar .
5. Aí vem o erro. O resultado:
   " Falha na atualização! Consulte o log abaixo para obter mais informações.
   Selecione_ou_outro
   • Erro na instalação / atualização
   • Falha na transferência de arquivos, motivo: não é possível copiar D:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txtpara /Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt. "
6. OK, estou começando a tentar inspecionar os possíveis motivos.
   • Aqui está o que os meus Drupal estrutura de diretório parecerá: . Defino ../tmpcomo o diretório temporário (in /admin/config/media/file-system), os arquivos Drupal estão htdocs. Isso está correto, pois eu posso instalar módulos via GUI, como mencionei acima.
   • Quando tento entrar no htdocs/sites/all/modules/select_or_otherdiretório, não consigo, porque recebo um "Acesso negado no arquivo ......sites/all/modules/select_or_other!" ao abrir em Total Commander, e " ...sites/all/modules/select_or_othernão é acessível Acesso negado." quando abrir no Windows Explorer: ,
   • OK, clique com o botão direito do mouse na pasta e abra o Unlocker por meio de seu assistente no menu de contexto. Ele diz que este diretório está bloqueado por php-cgi.exe: Eu clico em "Desbloquear tudo" e a pasta agora pode ser excluída por si mesma (já que não está mais bloqueada por php-cgi.exe), então simplesmente
   • Eu posso encontrar o diretório do módulo select_or_other atualizado em tmp:
   • então eu tenho que movê-lo manualmente para o sites/all/modulesdiretório.

Quais podem ser os possíveis motivos do bloqueio do diretório php-cgi.exe? (Talvez o Windows cache de extensão 1.1 para PHP 5.3 instalado via Web Platform Installer? Mas, se sim, por que é que, por exemplo, a eliminação de imagens ou similar, através do GUI funciona corretamente?)
O que posso fazer para evitar este problema, e deixar "Update gerente "trabalho?

isso não é seguro que permite gravar arquivos da interface do usuário Drupal para atualização de módulos, em vez disso, use ftp.

mas se você quiser, acesse o painel plesk de hospedagem explore o diretório httpdocs, clique com o botão direito do mouse e, em seguida, com permissão, agora com permissão, dê permissão de gravação ao usuário do pool de aplicativos,

obrigado

A razão para o php-cgi ter o bloqueio é por causa da maneira "peculiar" que o Windows lida com o acesso a arquivos e o php / iis lida com o "cache". Basicamente, você acabou de criar o diretório e tentou acessá-lo, mas o identificador que o criou não foi liberado (portanto, ainda estava bloqueado). Este não é um problema drupal, é um problema do IIS / PHP E não há solução alternativa conhecida que eu possa encontrar.

Basicamente, o aconselhamento básico de não usar o IIS é o melhor, já vi esse problema em mais do que apenas uma falha no IIS que resolvi mudando para o apache HTTPD (no win32). Lembre-se de que era para voltar à escola, com um projeto em que eu era obrigado a usar o Windows 2000.

a melhor maneira que conheço de executar o drupal no windows é através do apache (por causa do tratamento interno do php).

Algumas idéias para cavar na direção certa:

Se você tiver o mesmo problema do Drush, não tenho certeza se este é um problema do IIS. O Drush não está apenas executando o PHP a partir da linha de comando sem o IIS? Você pode tentar fazer isso parando o IIS (iisreset / stop) e executando o comando Drush update e espero que você obtenha o mesmo resultado.

A outra coisa (desculpe, não tenho reputação suficiente para comentar diretamente a resposta de Lawri):

"Basicamente, você acabou de criar o diretório e tentou acessá-lo, mas o identificador que o criou não foi liberado"

Isso é mesmo verdade? Na postagem original, parece que ele criou a pasta em "tmp", mas o bloqueio está na pasta já existente em "httpdocs".

Meu palpite é que o php-cgi tenta copiar do tmp para o httpdocs, falha por um motivo e não remove o bloqueio. Portanto, quando você investiga após a falha, vê um bloqueio nos httpdocs, mas acho que o motivo inicial da falha não é um bloqueio, talvez seja um problema de permissão na pasta tmp!