同じボリューム内でファイルを移動するときにファイルのアクセス許可が保持されるのはなぜですか？
場合によっては、ファイルのアクセス許可が、ファイルが含まれているフォルダーとは異なるという問題が発生します。
今、私はこれの背後にある理由を説明する KB記事 があることを知りました：
デフォルトでは、オブジェクトは、作成時、または親フォルダーにコピーまたは移動されたときに、親オブジェクトからアクセス許可を継承します。 このルールの唯一の例外は、オブジェクトを同じボリューム上の別のフォルダーに移動した場合に発生します。この場合、元の権限が保持されます。
そのため、ユーザーはファイルをあるフォルダーから別のフォルダーに移動し、元のフォルダーからのアクセス許可は保持されました。
私の質問は、なぜこの例外が存在するのかということです。これの背後にある理由は何ですか？
私はこれをブログ投稿で説明しました http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-権限/ ただし、以下でも説明します。
ファイルをコピーするときは、新しいファイルを作成して新しいアクセス許可のセットを割り当てる必要があるため、ご存知のように親フォルダーからアクセス許可を取得します。
ファイルが別のボリュームに移動されると、実際には、ファイルが新しいボリュームにコピーされ、古いファイルが削除されます。したがって、これは新しいファイルであり、アクセス許可を設定する必要があるため、上記と同じプロセスが繰り返されます。
ファイルが同じボリューム内で移動された場合、実際には何も起こりません（ディスクレベルで）。ファイルの論理パスの場所を変更するだけです。ディスク上の実際のデータと物理ファイルは、変更または変更されていません。 5GBのファイルを同じドライブ上の別のフォルダに移動すると、ほぼ瞬時に実行されることに気づいたことがありますか？これが理由です。実際には移動していませんが、ファイルが論理的に存在する場所へのポインタが変更されているためです。変更されていないため、権限も変更されません。
これがこの動作の理由です。
編集：私が言及するのを忘れた何か... MSの記事は完全に正確ではありません。 MSの見積もり：
デフォルトでは、オブジェクトは、作成時、または親フォルダーにコピーまたは移動されたときに、親オブジェクトからアクセス許可を継承します。このルールの唯一の例外は、オブジェクトを同じボリューム上の別のフォルダーに移動した場合に発生します。この場合、元の権限が保持されます。
上記の引用は、明示的に定義されたsec権限（継承をオフにする）が付与されたオブジェクトにのみ適用されます。私のコメントで述べたように、ACLエントリを可能な限り効率的に保つことがすべてです。次の例を考えてみましょう。
説明を簡単にするために、ユーザーが権限のみを変更できるようにフォルダーが設定されているとします。この下には何千ものファイルがあり、明示的なアクセス許可が設定されているファイルはありません。ファイルごとにACLを作成するのは、まったく同じ権限であるため、あまり効率的ではありません。そのため、フォルダーに1つのACLエントリが設定されます。この次のビットを理解することは非常に重要です。ファイル自体にはACLパーマはありません。したがって、これらのファイルのいずれかを同じボリューム内の新しいフォルダーに移動すると、MSはpermsも一緒に移動すると主張します（上記の引用のとおり）。これを自問してください....どうやって？そもそもファイルに移動する権限はありませんでした。これは実際には正しくないので、今すぐテストして確認しました。ファイルの移動先のフォルダーに、全員のグループが権限のみを変更できるようにする権限があるとします。ファイルには直接ACLがないため、親フォルダーのACLを継承します。これは、権限がユーザーの変更（古いフォルダー）から全員の変更（新しいフォルダー）に変更されたことを意味します。
違いに気づきましたか？今回は、ファイルを同じボリューム内の別のフォルダーに移動すると、実際には権限が変更されましたが、MSはそうはしていません。 2000年以来、MSのドキュメントに間違いを見つけたばかりですか？
次に、明示的なアクセス許可を使用する場合の同じシナリオを見てください。このフォルダ内のファイルに明示的なアクセス許可を設定すると（継承はオフになります）、たとえば、ユーザーの読み取りアクセスが拒否された場合、このファイル専用の新しいACLエントリが作成されるようになりました。これで、ファイルを新しい場所に移動すると、ファイルに直接関連するACLエントリがあります。この場合、ファイルを同じボリューム内の新しい場所に移動すると、（MSが主張するように）そのアクセス許可が保持されます。
同じボリューム内でファイルを移動する場合従来はファイルシステムを再配置していました。ディレクトリのレベルでファイルのアクセス許可を変更すると、移動操作が終了した瞬間にそのファイルからロックアウトされる可能性があります。これは、たとえば、誤ってファイルをシステムに移動した場合や、特別な所有権を持つフォルダやその他の方法で保護されている場合には望ましくありません。ファイルの所有権を取得する（特権がある場合）か、特権アカウントでログを記録する以外に、間違いを修正する方法はありません。コンピュータの通常の日常の操作を考えると、ファイルシステムを制御できないことがわかります。
この動作は、ACLを使用するほとんどの（すべてではないにしても）オペレーティングシステムで一般的です。これは、ユーザーとアプリケーションが同様にボリューム内で通常のファイルシステム操作を保証します。
逆に、ボリューム間でファイルを移動する場合、従来は、何かまたは他の誰かが制御できるようにファイルを提供していました。ご存知のように、ファイルにターゲットフォルダーのアクセス許可を組み込むことは理にかなっています。これにより、ターゲットに必要なアクセス許可が与えられ、適切と思われる独自のファイルシステムを再配置できます。
当然、これは必ずしも望ましいとは限りません。そのため、移動およびコピー操作は、特別な権限継承ルールを使用して定義できます。同じ記事から：
ファイルやフォルダをコピーまたは移動するときにアクセス許可を保持するには、Xcopy.exeユーティリティを/ Oまたは/ Xスイッチとともに使用します。オブジェクトの元のアクセス許可は、新しい場所の継承可能なアクセス許可に追加されます。
オブジェクトをコピーまたは移動するときに、オブジェクトの元のアクセス許可を継承可能なアクセス許可に追加するには、Xcopy.exeユーティリティを–Oおよび–Xスイッチとともに使用します。
OKこれが本当のローダウンです。まず、単一のPCまたはサーバーについて話しているのでしょうか。サーバーについて話していると思います。つまり、A社のWintel管理者として、新しいサーバーのネットワークドライブにファイルシステムを作成します。部門に基づいています。つまり、各部門にはフォルダがあり、機密性の問題があるため、各フォルダには独自のACLがあります。これはおそらく標準ですが、そうですか？したがって、ファイルを別の部門のフォルダに移動する場合、いったいなぜそのファイルに新しいフォルダの権限を継承させたくないのでしょうか。私が言いたいのは、使用しないのになぜパーミッションベースのファイルシステムがあるのかということです。移動したファイル/フォルダが常に親フォルダのACLを継承することが重要である実際の例を紹介します。質問してください。
ボリューム内のファイルの移動またはボリュームXからボリュームYへのファイルの移動... what IS本質的な違いは？いくつかのファイルの場所を移動している-異なるボリューム間で移動するかどうかで、わずかな違いが生じる私が見る限り、企業環境。一方がデフォルトで継承を含み、もう一方がまだマッカーによって言及されていない本当の理由、つまり「効率」。ボリューム内でファイルをドラッグアンドドロップすると、インデックスエントリが変更されるだけです。 -ファイルは移動されず、ACL情報はそのままになります。操作が簡単になります。ただし、ファイルをボリューム間で移動する場合は、ファイルとそのACL haveを再定義する必要があるため、- 適切にそして継承を含めることは、回避可能なオーバーヘッドが発生しないため、理にかなっています。
マイクロソフトがこの問題に対処しない理由がわかりません。 Explorerのドラッグアンドドロップの一部としてダイアログボックスを含めるのは難しすぎるでしょうか？ 「アクセス権の異なる場所にファイルを移動しました。新しい親フォルダのアクセス許可を継承しますか？YまたはN？」のようなものです。
よろしく、ストーンジャイアント