Wyjaśniłem to w poście na blogu http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/, ale to wyjaśniono również poniżej.
Po skopiowaniu plik musi utworzyć zupełnie nowy plik i przypisać mu nowy zestaw uprawnień, aby uzyskać uprawnienia z folderu nadrzędnego, jak wiadomo.
Gdy plik jest przenoszony na inny wolumin, tak naprawdę dzieje się tak, że jest on kopiowany na nowy wolumin, a stary plik jest usuwany. Ten sam proces powtarza się jak powyżej, ponieważ jest to nowy plik i wymaga ustawionych uprawnień.
Gdy plik jest przenoszony w tym samym woluminie, tak naprawdę nic się nie dzieje (na poziomie dysku). Po prostu zmienia lokalizację ścieżki logicznej pliku. Rzeczywiste dane i fizyczny plik na dysku nie zostały zmienione ani zmienione. Czy zauważyłeś, że kiedy przenosisz plik 5 GB do innego folderu na tym samym dysku, dzieje się to prawie natychmiast? Właśnie dlatego, ponieważ tak naprawdę nie został przeniesiony, ale zmienił się wskaźnik do miejsca, w którym logicznie istnieje plik. Ponieważ nie został w żaden sposób zmodyfikowany, uprawnienia również się nie zmieniają.
To jest powód tego zachowania.
Edycja: Coś, o czym zapomniałem wspomnieć ... Artykuł MS nie jest całkowicie dokładny. Cytat MS:
Domyślnie obiekt dziedziczy uprawnienia po obiekcie nadrzędnym w momencie jego tworzenia lub podczas kopiowania lub przenoszenia do folderu nadrzędnego. Jedyny wyjątek od tej reguły występuje, gdy przenosisz obiekt do innego folderu na tym samym woluminie. W takim przypadku oryginalne uprawnienia zostaną zachowane.
Powyższy cytat dotyczy tylko obiektów, które otrzymały WYJĄTKOWO zdefiniowane uprawnienia sec (wyłącz dziedziczenie). Jak wspomniano w moich komentarzach, chodzi o to, aby wpisy ACL były jak najbardziej wydajne. Rozważ następujący przykład:
Aby wyjaśnienie było proste, załóżmy, że masz ustawiony folder umożliwiający użytkownikom modyfikowanie tylko praw. Poniżej znajdują się tysiące plików i żaden z nich nie ma ustawionych jawnych uprawnień. Tworzenie list ACL dla każdego pliku nie jest zbyt wydajne, ponieważ mają one dokładnie takie same perms, więc ustawia JEDEN wpis ACL dla folderu. Ten następny fragment jest bardzo WAŻNY do zrozumienia; same pliki nie mają ŻADNYCH ACL. Więc kiedy przenosisz którykolwiek z tych plików do nowego folderu w tym samym woluminie, MS twierdzi, że perms przenosi się z nim (jak wyżej cytat). Zadaj sobie to .... jak? W tym pliku nie było permsów. To jest właściwie niepoprawne i właśnie to przetestowałem, aby to potwierdzić. Powiedzmy, że folder docelowy, do którego przenosisz plik, ma perms, aby umożliwić wszystkim grupom modyfikowanie tylko praw. Ponieważ plik nie ma bezpośrednio listy ACL, dziedziczy listę ACL folderu nadrzędnego. Oznacza to, że perms zmieniły się od modyfikacji użytkowników (stary folder) do modyfikacji wszystkich (nowy folder).
Zauważ różnicę? Tym razem przeniesienie pliku do innego folderu w tym samym woluminie faktycznie zmieniło perms, coś, co MS mówi, że tego nie robi. Czy właśnie znalazłem błąd w dokumentacji MS od 2000 lol ??
Teraz spójrz na ten sam scenariusz, gdy używasz jawnych uprawnień. Jeśli ustawisz wyraźne uprawnienia do pliku w tym folderze (wyłączono dziedziczenie), co na przykład odmawia użytkownikom dostępu do odczytu, tworzy teraz NOWY wpis ACL specjalnie dla tego pliku. Teraz, kiedy przenosisz plik do nowej lokalizacji, ma on bezpośrednio powiązany z nim wpis ACL. W takim przypadku przeniesienie pliku do nowej lokalizacji w tym samym woluminie ZACHOWA swoje uprawnienia (jak twierdzi MS)!