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

9

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

Давайте возьмем пример:

  1. Страница доступных обновлений ( /admin/reports/updates/update):

    Доступные обновления

    Теперь я проверяю модуль Select (или другой), который нужно обновить ( не имеет значения, какой модуль я выбрал , результаты такие же !!, так что это всего лишь пример).

  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 структура каталогов выглядит следующим образом : Структура каталогов TC. Я установил ../tmpвременную директорию (in /admin/config/media/file-system), в которой находятся файлы Drupal htdocs. Это правильно, так как я могу устанавливать модули через графический интерфейс, как я упоминал выше.
    • Когда я пытаюсь войти в htdocs/sites/all/modules/select_or_otherкаталог, я не могу, потому что я получаю «Доступ запрещен для файла ......sites/all/modules/select_or_otherпри открытии в Total Commander, и « ...sites/all/modules/select_or_otherне доступен доступ запрещен.» при открытии в проводнике Windows: пытается открыть каталог в Total Commander,пытается открыть каталог в проводнике Windows
    • ОК, я щелкаю правой кнопкой мыши по папке и открываю Unlocker через его помощника в контекстном меню. Он говорит, что этот каталог заблокирован php-cgi.exe: Unlocker - каталог заблокирован php-cgi.exe я нажимаю «Разблокировать все», и теперь папка может быть удалена сама по себе (так как она больше не заблокирована php-cgi.exe), поэтому она просто
    • Я могу найти каталог обновленного модуля select_or_other в tmp: обновлен каталог модуля в <code> tmp </ code>
    • поэтому я должен вручную переместить его в sites/all/modulesкаталог.

Чем могут быть возможные причины блокировки каталога php-cgi.exe? (Может быть, расширение Windows Cache 1.1 для PHP 5.3 установлено через установщик веб-платформы? Но если да, то почему, например, удаление изображений или аналогичных объектов через графический интерфейс работает правильно?)
Что можно сделать, чтобы избежать этой проблемы, и разрешить "Обновить" менеджер "работа?

Sk8erPeter
источник
Я вижу точно такое же поведение с Drupal 7.15 на IIS7 / 2008R2. Было бы здорово исправить это.
Nic
@Nic: я согласен! :)
Sk8erPeter
Я видел это с перерывами. Из любопытства обновляет ли пул приложений разблокировку?
Брент
2
Я знаю, что это не по теме, но я должен сказать это - убежать от Drupal на IIS. Как я вижу на скриншотах, вы можете использовать его для локальной разработки. Проверьте WAMP или Acquia Dev Desktop . Если вам просто нужно использовать его на производственном сервере, проигнорируйте мой комментарий :) Я должен использовать IIS для определенных сайтов, и пока это не было хорошим опытом.
Арам Бояджян
@ Брент: я не знаю. После запуска страницы в Drupal файлы и каталоги, похоже, блокируются на неизвестный период. Кстати, я тоже использую Drush , и когда я хочу обновить модуль с помощью drush up -y, у меня возникает та же проблема: мне нужно разблокировать эти файлы и каталоги с помощью Unlocker, чтобы в противном случае я получил сообщение об ошибке, что эти каталоги не могут быть записаны / удалены, и процесс обновления прерывается. Если я использую Unlocker ДО запуска этого процесса, обновление прошло успешно.
Sk8erPeter

Ответы:

1

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

но если вы хотите, то перейдите на панель хостинга plesk, исследуйте каталог httpdocs, щелкните правой кнопкой мыши и затем по разрешению, теперь в разрешении дайте разрешение на запись пользователю пула приложений

Спасибо

bhupendraosd
источник
0

Причиной использования php-cgi блокировки является «своеобразный» способ, которым окна обрабатывают доступ к файлу, а php / iis обрабатывает «кэширование». По сути, вы просто создали каталог и попытались получить к нему доступ, но дескриптор, который его создал, не был освобожден (поэтому он все еще был заблокирован). Это не проблема drupal, это проблема IIS / PHP И я не могу найти никакого известного обходного пути.

По сути, лучше всего использовать базовый совет не использовать IIS, я видел эту проблему больше, чем просто друпал с IIS, который я решил, перейдя в apache HTTPD (на win32). Имейте в виду, что это было в школе, с проектом, где я должен был использовать Windows 2000.

лучший способ работы с drupal на windows - через apache (из-за внутренней обработки php).

LVB
источник
0

Некоторые идеи копать в правильном направлении:

Если у вас есть та же проблема с Drush, то я не уверен, что это проблема IIS. Разве Drush не просто выполняет PHP из командной строки без IIS? Вы можете попробовать это, остановив IIS (iisreset / stop), а затем запустив команду обновления Drush, и я ожидаю, что вы получите тот же результат.

Другая вещь (извините, у меня недостаточно репутации, чтобы напрямую комментировать ответ Лори):

«По сути, вы просто создали каталог и попытались получить к нему доступ, но дескриптор, который его создал, не был освобожден»

Это правда? Из исходного поста похоже, что он создал папку в «tmp», но блокировка уже существующей папки в «httpdocs».

Я предполагаю, что php-cgi пытается скопировать из tmp в httpdocs, по какой-то причине терпит неудачу и не снимает блокировку. Поэтому, когда вы исследуете после сбоя, вы видите блокировку на httpdocs, но я думаю, что первоначальная причина сбоя не в блокировке, это может быть проблема с правами доступа к папке tmp!

dustinmoris
источник
если бы это было так, он также не мог переместить его «вручную», каталог создается как часть процесса обновления. IIS участвует через свой интерфейс CGI, который известен тем, что вызывает странные ошибки. и сообщение об ошибке не является «не может получить доступ», но «не может скопировать в» ошибку.
LvB