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

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

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

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

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

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

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

Есть идеи? Какие дополнительные проверки учетных данных делает Mercurial, которые могут вызвать это?

ОБНОВЛЕНИЕ:

После совета от Вима я начал проверять разрешения для различных объектов репо, используя cacls. Это инструмент Windows, который «отображает или изменяет списки управления доступом к файлам».Я попросил пользователя создать новое репо, а затем сделал снимок разрешений. Затем я зарегистрировал файл в том же репо и сделал еще один снимок изменений.

Оказывается, есть несколько разрешений файла репо, которые обновляются в результате этого: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 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 отражали домен и идентификатор пользователя. После того, как я зарегистрировался, они были обновлены до моего (мы находимся в одном домене, но ID пользователя, очевидно, отличается). Я мог регистрировать вещи и выходить, хотя мой ID пользователя не был в списке, потому что я являюсь членом группы BUILTIN \ Administrators. Пользователь с проблемой нет. Итак, я предполагаю, что после того, как я все проверил, система больше не считала его авторизованным пользователем с доступом для записи (BUILTIN \ User: R означает доступ только для чтения) и, следовательно, вызвала отказ в доступе.

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