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