Проблема IIS з Drupal - Менеджер оновлень: Не вдалося оновити! Каталоги заблоковані php-cgi.exe

У мене є певна проблема при використанні "Менеджера оновлень" на графічному інтерфейсі. Деякі каталоги блокуються php-cgi.exe, і, таким чином, заміна оригінальних каталогів знову завантаженими (які свіжішими) не є успішною.
Але я повинен відзначити , що це не проблема дозволу, оскільки модулі можуть отримати встановлений з допомогою «Встановити з URL» на /admin/modules/install, і працювати без проблем.

Візьмемо приклад:

1. Сторінка доступних оновлень ( /admin/reports/updates/update):

   

   Тепер я перевіряю Вибір (або інший) модуль для оновлення ( не має значення, який модуль я вибираю , результати такі ж !!, тому це просто приклад).

2. Я натискаю кнопку "Завантажити ці оновлення" .

3. Гаразд, оновлений екземпляр модуля завантажується без проблем:
   " Оновлення завантажено успішно ":
4. Тепер натискаю на Продовжити .
5. Ось приходить помилка. Результат:
   " Оновлення не вдалося! Для отримання додаткової інформації див. Журнал нижче.
   Select_or_other
   • Помилка встановлення / оновлення
   • Не вдалося перенести файл, причина: Неможливо скопіювати D:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txtв /Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt. "
6. Гаразд, я починаю намагатися перевірити можливі причини.
   • Ось що мій Drupal структура каталогів виглядає наступним чином : . Я встановив ../tmpтимчасовий каталог (в /admin/config/media/file-system), файли Drupal є htdocs. Це правильно, оскільки я можу встановлювати модулі через GUI, як я вже згадував вище.
   • Коли я намагаюся увійти в htdocs/sites/all/modules/select_or_otherкаталог, я не можу, тому що я отримую "Доступ заборонений у файлі ......sites/all/modules/select_or_other!" при відкритті в Total Commander, і « ...sites/all/modules/select_or_otherне доступний доступ заборонений.» при відкритті в провіднику Windows: ,
   • Гаразд, я клацніть правою кнопкою миші папку та відкрию Unlocker через свого помічника в контекстному меню. У ній написано, що цей каталог заблоковано php-cgi.exe: Я натискаю "Розблокувати все", і папка тепер може видалятися з себе (оскільки вона більше не заблокована php-cgi.exe), так що просто
   • Я можу знайти оновлений каталог модуля select_or_other у tmp:
   • тому мені доведеться вручну перемістити його в sites/all/modulesкаталог.

Які можуть бути можливі причини блокування каталогу php-cgi.exe? (Можливо, Windows Cache Extension 1.1 для PHP 5.3 встановлений через інсталятор веб-платформи? Але якщо так, то чому, наприклад, видалення зображень чи подібного через GUI працює правильно?)
Що я можу зробити, щоб уникнути цієї проблеми, і нехай "Оновити" менеджер "робота?

це не є безпечним, що дозволяє записувати файл з інтерфейсу користувача Drupal для оновлення модулів, замість цього використовуйте ftp.

але якщо ви хочете, тоді перейдіть на панель plesk хостингу, вивчіть каталог каталогу httpdocs, клацніть правою кнопкою миші, а потім на дозвіл.

Дякую

Причина php-cgi для блокування полягає в тому, що "своєрідний" спосіб Windows обробляє доступ до файлів, а php / iis обробляє "кешування". В основному ви просто створили каталог і спробували отримати доступ до нього, але ручка, яка його створила, не була випущена (тому вона все ще була заблокована). Це не друпальське питання, це питання IIS / PHP. І немає відомого рішення, яке я міг би знайти.

В основному, рекомендувати базову пораду не використовувати IIS найкраще, я бачив цю проблему в більш ніж просто drupal з IIS, яку я вирішив, перейшовши на Apache HTTPD (на win32). Зверніть увагу, що було в школі, з проектом, коли мені потрібно було використовувати Windows 2000.

найкращий спосіб мене знати, як запускати drupal на Windows - це через apache (через внутрішню обробку php).

Деякі ідеї копати в правильному напрямку:

Якщо у вас є та сама проблема з Друшем, то я не впевнений, чи це проблема IIS. Хіба Drush не просто виконує PHP з командного рядка без IIS? Ви можете спробувати це, зупинивши IIS (iisreset / stop) і запустивши команду Drush update, і я би сподівався, що ви отримаєте такий же результат.

Інша річ (вибачте, у мене недостатньо репутації, щоб прямо коментувати відповідь Лорі):

"В основному ви просто створили каталог і намагалися отримати доступ до нього, але ручка, яка його створила, не була випущена"

Це справді правда? З оригінальної публікації виглядає так, що він створив папку в "tmp", але замок знаходиться на вже існуючій папці в "httpdocs".

Я здогадуюсь, що php-cgi намагається скопіювати з tmp в httpdocs, не вдалося з причини та не знімає блокування. Отже, коли ви розслідуєте після відмови, ви бачите блокування на httpdocs, але я думаю, що початкова причина відмови - це не блокування, це може бути проблема дозволу в папці tmp врешті-решт!