Почему Mercurial возвращает "Abort: Access Denied" при попытке нажать репозиторий?

У меня возникла проблема с тем, что пользователь не смог подтолкнуть свои коммиты к хранилищу Mercurial и недоумевал, почему он не работает для него. Я пробовал несколько вещей, чтобы понять, что, Googling не помогает мне ничего полезного... так что я здесь.

Сначала конфигурация. У нас есть Windows XP SP2 x64 машина в нашей сети, действующая как наш официальный сервер репозитория. Это содержит несколько репозиториев. Мы клонируем/нажимаем/тянем, используя папку на этом диске, который является общим. Разрешения предоставляются каждому для доступа к чтению. Пользователи, которые могут нажать (включая пользователя с проблемами), получают полный контроль. Пользовательский компьютер основан на Win XP. Моя машина (используемая для устранения неполадок) также основана на Win XP.

Во-вторых, симптомы. Пользователь использует TortoiseHg 2.1.1 для выполнения своей работы. Он может клонировать только штраф, совершает свои локальные репо, а-о-к и т.д. Однако, когда он пытается нажать, TortoiseHg возвращает код "abort, ret 255". Не очень полезно. Итак, мы перешли в командную строку и выпустили "hg push -v -debug". Здесь он возвращает "abort: Access denied". Этот же пользователь не может писать в общую папку сервера без проблем - он может создавать файлы, каталоги и удалять их одинаково. Таким образом, чтение/запись доступа к диску/папке не является проблемой.

В-третьих, наши результаты экспериментов. Вот некоторые странные результаты тестирования. Пользователь создал новое локальное тестовое репо. Я вошел в серверную машину и создал тестовое репо для него. Пользователь проверил файл, а затем перетащил его на тестовое репо на серверной машине. Это отлично работает. Нет прерываний. Жизнь была хорошей. Он смог сделать еще несколько нажатий, и он продолжал работать, как ожидалось. Затем я клонировал репо на свою машину, обновил файл и вытолкнул его обратно. После того, как пользователь потянул мои изменения и попытался вернуться на сервер, он снова столкнулся с ужасным сообщением "Отказано в доступе". Между тем, я все еще могу обновить проект без проблем.

В качестве другого эксперимента мы вышли из системы, а другой пользователь зашел в систему. Они сделали это и смогли нажать на серверную репо без проблем. Исходный пользователь регистрируется снова, вносит некоторые изменения и т.д. И снова попадает на кирпичную стену "Доступ запрещен".

Насколько мы можем судить, проблема не связана с учетными данными Windows. В противном случае мы ожидаем, что создание произвольных файлов в общей папке сервера не будет работать. Кроме того, до тех пор, пока я не сделаю обновление тестового репо, созданного пользователем, он мог бы просто нажать на это конкретное репо.

Любые идеи? Какие дополнительные проверки учетных данных являются Mercurial, что может вызвать это?

UPDATE:

После подсказки от Wim я начал смотреть на разрешения на различные объекты репо, используя 'cacls'. Это инструмент Windows, который "отображает или изменяет списки управления доступом к файлам". У меня был пользователь, создавший новое репо, а затем сделал снимок разрешений. Затем я проверил файл в том же репо и сделал еще один снимок изменений.

Оказывается, есть несколько разрешений файлов репо, которые обновляются в результате: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, ветки, 00changelog.i, 00manifest.i, undo, и единственный файл репозитория. Все эти файлы имели разрешения, похожие на следующие:

C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F 
                                         NT AUTHORITY\SYSTEM:F 
                                         DOMAINxxxx\USERIDxxxx:F 
                                         BUILTIN\Users:R

(фактические значения DOMAINxxxx и USERIDxxxx изменены). До моей регистрации DOMAINxxxx и USERIDxxxx отображали домен пользователя и идентификатор пользователя. После моей регистрации они обновились до моего (мы находимся в том же домене, но идентификатор пользователя явно отличается.) Я смог проверить все, даже если мой идентификатор пользователя не был указан, потому что я член группы BUILTIN\Administrators. У пользователя с проблемой нет. Итак, я предполагаю, что после того, как я проверил ситуацию, система больше не считала его авторизированным пользователем с доступом для записи (BUILTIN\User: R указывает доступ только для чтения) и, следовательно, вызвал отказ в доступе.

У меня есть жуткое исправление Q & D прямо сейчас (теперь пользователь входит в группу Admin...). Реальное решение будет заключаться в том, чтобы вернуть репо из Windows Sharing и на правильном конфигурации сервера.

Ответ 1

Он смог сделать еще несколько нажатий, и он продолжал работать, как ожидалось. Затем я клонировал репо на свою машину, обновил файл и вытолкнул его обратно. После того, как пользователь выполнил мои изменения и попытался вернуться к серверу, он снова столкнулся с ужасным сообщением "Отказано в доступе".

Похоже, что ваш push создает или изменяет файлы в .hg-папке таким образом, что они (или становятся) недоступны для другого пользователя.

Я не разбираюсь в разрешениях файлов NTFS, но думаю, что вы можете исправить такие ситуации, заставив все содержимое папки наследовать свои разрешения. Попробуйте выбрать "Заменить все права дочерних объектов с помощью наследуемых разрешений от этого объекта" в настройках расширенной безопасности этой папки.

Однако совместное использование файлов репозитория напрямую при совместном использовании файлов Windows не рекомендуется . Для обеспечения производительности, целостности данных и безопасности необходим серверный процесс между пользователями и файлами репозитория. Без такого привратника предоставление права доступа также означает предоставление возможности уничтожать/повреждать файлы репозитория (или, как вы выяснили в этом случае, изменять их разрешения).

Подробнее о других параметрах см. публикация Mercurial Repositories на вики-странице Mercurial.

Ответ 2

При попытке зафиксировать в моем локально клонированном репозитории репо кода на моем общем сетевом ресурсе я получал такое же сообщение об ошибке:

00manifest.i Access is denied

Наверное, слишком упрощен, но удаление некоторых разрешений только для чтения для файлов-нарушителей сделало мой hg commit работоспособен.

Ответ 3

Я получал точно такое же сообщение об ошибке при попытке hg push в командной строке Windows. Недавно я получил новый профиль пользователя после того, как старый был поврежден. Затем я столкнулся с этой ошибкой "Отказано в доступе". В TortoiseHg я получил аналогичное сообщение "Aborted: Error 255".

Я попробовал совет, приведенный здесь Wim Coenen, поскольку он, казалось, соответствовал; учитывая мои новые учетные данные пользователя. В конце концов, я обнаружил ошибку для плохо установленной Windows Git. Это было неудачно, когда я использовал репозитории с суб-репозициями git.

В случае, если другие имеют аналогичную проблему с git sub-repos:

Убедитесь, что git установлен правильно. Я удалил и полностью установил его. (См. https://code.google.com/p/msysgit/downloads/list для последней версии).
Убедитесь, что путь к git находится в переменной среды пути. (Щелкните правой кнопкой мыши Мой компьютер → вкладка Дополнительно → переменные среды). Не забывайте, что некоторым приложениям не нравятся пути Windows с пробелами, поэтому вам может потребоваться заменить "Program Files" на "PROGRA ~ 1" (возможно, "PROGRA ~ 2" в 64-битных системах).
Если вы используете прокси-сервер, убедитесь, что HTTP_PROXY и HTTPS_PROXY в переменных среды также установлены правильно.

Ответ 4

У меня была такая же проблема abort: Access is denied. Причиной был мой брандмауэр (Privatefirewall), который молча блокировал некоторые действия hg.