Я пояснив це в публікації в блозі http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/, але це також пояснено нижче.
Коли файл копіюється, він повинен створити абсолютно новий файл і призначити йому новий набір дозволів, тому він отримує дозволи з батьківської папки, як відомо.
Коли файл переміщується в інший том, що насправді відбувається, це те, що він копіюється в новий том, а старий файл видаляється. Отже, повторюється той самий процес, що і вище, оскільки це знову новий файл і потрібні дозволи.
Коли файл переміщується в одному обсязі, насправді нічого не відбувається (на рівні диска). Він просто змінює логічне розташування файлу. Фактичні дані та фізичний файл на диску не торкнулися та не змінені. Ви коли-небудь помітили, коли ви переміщаєте файл 5 Гб в іншу папку на тому ж диску, це робиться майже миттєво? Ось чому, оскільки він насправді не перемістився, але вказівник на те, де файл логічно існує, змінився. Оскільки це не було змінено жодним чином, дозволи також не змінюються.
Це причина такої поведінки.
Редагувати: Щось я забув згадати ... Стаття MS не зовсім точна. Цитата MS:
За замовчуванням об’єкт успадковує дозволи від свого батьківського об'єкта під час створення або коли він скопійований або переміщений у свою батьківську папку. Єдиний виняток із цього правила відбувається, коли ви переміщуєте об’єкт до іншої папки на тому ж томі. У цьому випадку початкові дозволи зберігаються.
Вищенаведена цитата стосується лише об'єктів, яким надано ЕКСПЛІАТНО визначені дозволи сек (виключення успадкування). Як було сказано в моїх коментарях, справа полягає в тому, щоб максимально ефективно робити записи ACL. Розглянемо наступний приклад:
Щоб пояснення не було простим, скажімо, у вас встановлена папка, яка дозволяє користувачам змінювати права лише. Нижче цього тисячі файлів, і жоден з них не має явних дозволів. Створювати ACL-файли для кожного файлу не дуже ефективно, оскільки вони абсолютно однакові perms, тому він встановлює ONE ACL-запис для папки. Цей наступний біт дуже важливий для розуміння; самі файли НЕ мають ACL PERMS. Отже, коли ви переміщаєте будь-який із цих файлів у нову папку того самого обсягу, MS стверджує, що перехідні речовини переміщуються разом із ним (як вище цитата). Задайте собі питання .... як? Перш за все у файлі не було пермісів, щоб переміщатися поперек. Це насправді неправильно, і я просто перевірив це зараз, щоб підтвердити. Скажімо, папка призначення, в яку ви переміщуєте файл, має perms, щоб дозволити всім групам змінювати права лише. Так як у файлу безпосередньо немає ACL, він успадковує ACL батьківської папки. Це означає, що хімічні речовини змінилися від змін користувачів (стара папка) до всіх модифікованих (нова папка).
Помітьте різницю ?? Цього разу переміщення файлу в іншу папку в тому ж обсязі насправді змінило візуалізацію, що МС каже, що цього не робить. Я щойно знайшов помилку в документації на MS, починаючи з 2000 року?
Тепер подивіться на той самий сценарій, коли використовуєте явні дозволи. Якщо ви встановите явні дозволи на файл у цій папці (спадкування вимкнено), який, наприклад, забороняє користувачам читати доступ, тепер він створює НОВУ запис ACL спеціально для цього файлу. Тепер, коли ви переміщуєте файл на нове місце, у ньому є запис ACL, безпосередньо пов’язаний з ним. У цьому випадку переміщення файлу на нове місце в тому ж обсязі ЗАБЕЗПЕЧАЄ свої дозволи (як стверджує MS)!