私は、ユーザがMercurialリポジトリにコミットをプッシュできないという問題に遭遇しています。なぜそれが彼のために働いていないのか困惑しています。私は何が起こっているのか把握するためにいくつかのことを試しましたが、グーグルが何か助けになりません...だから私はここにいます。なぜMercurialはリポジトリをプッシュしようとすると "Abort：Access is Denied"を返すのですか？
まず、構成。私たちは公式のリポジトリサーバとして機能する私たちのネットワーク上のWindows XP SP2 x64マシンを持っています。これにはいくつかのリポジトリが含まれています。共有されているドライブ上のフォルダを使用してクローン/プッシュ/プルします。アクセス権はすべてのユーザーに読み取りアクセス権が与えられます。プッシュできるユーザー（問題のあるユーザーを含む）は完全に制御されます。ユーザーのマシンはWin XPベースです。私のマシン（物事のトラブルシューティングに役立つ）は、Win XPベースです。
第2に、症状。ユーザーはTortoiseHg 2.1.1を使用して作業を行っています。彼はちょうど良いクローンを作成することができますが、彼の地元のレポにコミットすることはa-o-kなどです。しかし、彼がプッシュしようとすると、TortoiseHgは "abort、ret 255"というコードを返します。それほど役に立たない。そこで、コマンドラインに行き、 "hg push -v --debug"を発行しました。ここでは、 "abort：Access is Denied"が返されます。この同じユーザーはサーバーの共有フォルダに問題なく書き込みできます。ファイルやディレクトリを作成して削除することもできます。したがって、ドライブ/フォルダへのアクセスの読み取り/書き込みは問題ではありません。
第3に、我々の実験結果。ここでは、テストからの奇妙な結果があります。ユーザーは新しいローカルテストレポを作成しました。私はサーバーマシンにログインし、彼にプッシュするテストレポを作成しました。ユーザーがファイルをチェックインし、サーバーマシン上のテストレポにプッシュしました。これはうまくいった。中止しない。人生は良かった。彼はもう少しプッシュすることができ、期待通りに動作し続けました。その後、私のマシンにレポをクローンし、ファイルを更新し、それを元に戻しました。ユーザーが変更を取り込んでサーバーにプッシュバックしようとした後、再び「アクセスが拒否されました」というメッセージが表示されました。一方、私はまだ問題なくプロジェクトを更新することができます。
もう1つの実験として、ユーザーはログアウトし、別のユーザーがログインしました。問題なくサーバーリポジトリにプッシュできるようになりました。元のユーザーが元に戻ったり、いくつかの変更を加えたりして、再び「アクセスが拒否されました」というレンガの壁に当たっています。
私たちが知る限り、問題はWindowsの資格情報とは関係ありません。そうしないと、サーバーの共有フォルダに任意のファイルを作成しても機能しないことが予想されます。さらに、ユーザーが作成したテストレポを更新するまで、彼はその特定のレポをうまく押し込めました。
アイデア？これを引き起こすかもしれないMercurial製作は何ですか？
UPDATE：ヴィムから先端の後
、私は「CACLS」を使用してレポのさまざまなオブジェクトのパーミッションを見て始めました。これは、「ファイルのアクセス制御リストを表示または変更する」Windowsツールです。ユーザーに新しいリポジトリを作成させてから、その権限のスナップショットを作成しました。同じレポにファイルをチェックインし、変更のスナップショットをもう一度撮りました。
undo.bookmarks、undo.branch、undo.desc、undo.dirstate、branchheads、00changelog.i、00manifest.i、undoの結果、更新されるrepoファイルのアクセス許可がいくつかあります。 、およびリポジトリの単一のファイルです。これらのファイルには、次のような権限があります。
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がリストされていませんでした内外に私は物事をチェックすることができました（私たちは、同じドメインにしているが、ユーザーIDは明らかに異なっている。）鉱山に更新しましたm BUILTIN \ Administratorsグループのメンバ。問題のあるユーザーはそうではありません。だから、私は物事をチェックした後、システムは彼が書き込みアクセス権（BUILTIN \ User：Rは読み取り専用アクセスを示す）を持つ信用度の高いユーザーとして認識しなくなり、アクセス拒否を引き起こしたと推測しています。
私はひどいQ & Dの修正プログラムを今すぐ入手しています（ユーザーは現在Adminグループに属しています...）。実際の修正は、Windows共有のレポを取得してから適切なサーバー構成。
サーバー上の.hg/store/dataディレクトリにあるファイルを調べて、ユーザーが各ファイルにアクセスできるかどうかを確認できますか？新しいファイルをリポジトリにプッシュすると、そこにメタデータが保存され、プッシュできるようにこれらのファイルに書き込みアクセス権が必要です。 – krtek