Pourquoi les autorisations de fichiers sont-elles conservées lors du déplacement de fichiers dans le même volume?

Parfois, nous avons le problème qu'un fichier dispose d'autorisations différentes du dossier dans lequel il se trouve.

Maintenant, j'ai découvert qu'il existe un article de la base de connaissances expliquant la raison de cela:

Par défaut, un objet hérite des autorisations de son objet parent, soit au moment de sa création, soit lorsqu'il est copié ou déplacé vers son dossier parent. La seule exception à cette règle se produit lorsque vous déplacez un objet vers un autre dossier sur le même volume. Dans ce cas, les autorisations d'origine sont conservées.

L'utilisateur a donc déplacé le fichier d'un dossier à un autre et les autorisations du dossier d'origine ont été conservées.

Ma question est maintenant: pourquoi cette exception existe-t-elle? Quel est le raisonnement derrière cela?

Je l'ai expliqué dans un article de blog http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ mais il est également expliqué ci-dessous.

Lorsqu'un fichier est copié, il doit créer un nouveau fichier et lui affecter un nouvel ensemble d'autorisations, afin qu'il obtienne les autorisations du dossier parent comme vous le savez.

Lorsqu'un fichier est déplacé vers un autre volume, ce qui se passe réellement est qu'il est copié sur le nouveau volume et que l'ancien fichier est supprimé. Ainsi, le même processus est répété comme ci-dessus car il s'agit à nouveau d'un nouveau fichier et des autorisations doivent être définies.

Lorsque le fichier est déplacé dans le même volume, rien ne se passe vraiment (au niveau du disque). Il modifie simplement l'emplacement du chemin logique du fichier. Les données réelles et le fichier physique sur le disque n'ont pas été touchés ou modifiés. Avez-vous déjà remarqué que lorsque vous déplacez un fichier de 5 Go vers un autre dossier sur le même lecteur, cela se fait presque instantanément? C'est pourquoi, car il n'a en fait pas bougé mais le pointeur vers l'emplacement logique du fichier a changé. Comme il n'a été modifié d'aucune façon, les autorisations ne changent pas également.

C'est la raison de ce comportement.

Edit: quelque chose que j'ai oublié de mentionner ... L'article MS n'est pas tout à fait exact. Citation MS:

Par défaut, un objet hérite des autorisations de son objet parent, soit au moment de sa création, soit lorsqu'il est copié ou déplacé vers son dossier parent. La seule exception à cette règle se produit lorsque vous déplacez un objet vers un autre dossier sur le même volume. Dans ce cas, les autorisations d'origine sont conservées.

La citation ci-dessus s'applique uniquement aux objets qui ont reçu des autorisations SEC EXPLICITEMENT définies (désactivez l'héritage). Comme mentionné dans mes commentaires, il s'agit de maintenir les entrées ACL aussi efficaces que possible. Prenons l'exemple suivant:

Pour garder l'explication simple, supposons que vous ayez un ensemble de dossiers pour permettre aux utilisateurs de modifier les droits uniquement. En dessous, il y a des milliers de fichiers et aucun d'entre eux n'a défini d'autorisations explicites. Il n'est pas très efficace de créer des ACL pour chaque fichier car ce sont exactement les mêmes perms donc il définit UNE entrée ACL pour le dossier. Ce bit suivant est très IMPORTANT à comprendre; les fichiers eux-mêmes n'ont AUCUN ACL. Ainsi, lorsque vous déplacez l'un de ces fichiers dans un nouveau dossier dans le même volume, MS affirme que les perms se déplacent avec lui (comme ci-dessus). Demandez-vous ceci ... comment? Il n'y avait pas de perms sur le fichier en premier lieu pour traverser. C'est en fait incorrect et je viens de le tester maintenant pour le confirmer. Supposons que le dossier de destination vers lequel vous déplacez le fichier possède des autorisations pour autoriser le groupe tout le monde à modifier les droits uniquement. Eh bien, puisque le fichier n'a pas d'ACL directement, il hérite de l'ACL du dossier parent. Cela signifie que les perms sont passés des utilisateurs à modifier (ancien dossier) à tout le monde à modifier (nouveau dossier).

Remarquez la différence ?? Cette fois-ci, le déplacement d'un fichier vers un autre dossier du même volume a en fait changé les perms, ce que MS dit qu'il ne fait pas. Ai-je trouvé une erreur dans la documentation MS depuis 2000 lol ??

Regardez maintenant le même scénario lorsque vous utilisez des autorisations explicites. Si vous définissez des autorisations explicites sur un fichier de ce dossier (héritage désactivé), ce qui, par exemple, refuse aux utilisateurs l'accès en lecture, il crée désormais UNE NOUVELLE entrée ACL spécifiquement pour ce fichier. Désormais, lorsque vous déplacez le fichier vers un nouvel emplacement, il a une entrée ACL directement associée. Dans ce cas, le déplacement d'un fichier vers un nouvel emplacement dans le même volume conserve ses autorisations (comme le prétend MS)!

Lorsque vous déplacez des fichiers dans le même volume, vous réorganisez traditionnellement votre système de fichiers . La modification des autorisations de fichier au niveau du répertoire peut vous bloquer hors de ce fichier au moment où l'opération de déplacement est terminée. Cela n'est pas souhaitable si, par exemple, vous venez de déplacer accidentellement un fichier vers un système, ou un dossier avec des autorisations de propriété spéciales ou autrement protégé. Il n'y aurait aucun moyen de corriger l'erreur autre que de prendre possession du fichier (si vous avez les privilèges) ou de vous connecter avec un compte privilégié. Compte tenu du fonctionnement quotidien normal d'un ordinateur, vous pouvez constater que vous n'avez aucun contrôle sur votre système de fichiers.

Ce comportement est courant dans la plupart des systèmes d'exploitation (sinon tous) utilisant ACL. Il garantit le fonctionnement normal du système de fichiers dans un volume par les utilisateurs et les applications.

Inversement, lorsque vous déplacez des fichiers entre des volumes, vous donnez traditionnellement un fichier pour qu'il soit contrôlé par quelque chose ou quelqu'un d'autre. Il est logique, comme vous le savez bien, que le fichier incorpore ensuite les autorisations du dossier cible, ce qui donnera à la cible les autorisations nécessaires pour réorganiser son propre système de fichiers comme bon lui semble.

Naturellement, ce n'est pas toujours souhaitable. Pour cette raison, les opérations de déplacement et de copie peuvent être définies avec des règles d'héritage d'autorisations spéciales. Du même article:

• Pour conserver les autorisations lorsque des fichiers et des dossiers sont copiés ou déplacés, utilisez l'utilitaire Xcopy.exe avec / O ou le commutateur / X. Les autorisations d'origine de l'objet seront ajoutées aux autorisations héritables dans le nouvel emplacement.

• Pour ajouter les autorisations d'origine d'un objet à des autorisations héritables lorsque vous copiez ou déplacez un objet, utilisez l'utilitaire Xcopy.exe avec les commutateurs –O et –X.

OK C'est le vrai bas. Tout d'abord - parlons-nous d'un seul PC ou d'un serveur? Je suppose que nous parlons d'un serveur. Donc .... en tant qu'administrateur Wintel de la société A, vous créez un système de fichiers sur un lecteur réseau sur votre nouveau serveur. Vous le basez sur les départements, c'est-à-dire que chaque département a un dossier et que chaque dossier a sa propre liste de contrôle d'accès en raison de problèmes de confidentialité, comme c'est probablement la norme - oui? Par conséquent, si vous allez déplacer un fichier vers le dossier d'un autre service, pourquoi diable ne voudriez-vous PAS qu'il hérite des perms de son nouveau dossier? Ce que je veux dire, c'est ... pourquoi avoir un système de fichiers basé sur les autorisations si vous ne comptez pas l'utiliser? Je peux vous donner un exemple concret où il est important que les fichiers / dossiers déplacés héritent toujours de l'ACL de leur dossier parent, demandez-moi.

Déplacer des fichiers dans un volume ou les déplacer du vol X au vol Y ... quelle est la différence essentielle? Vous déplacez l'emplacement de certains fichiers - sur différents volumes ou non, cela fait une petite différence dans un environnement d'entreprise pour autant que je puisse voir. La vraie raison pour laquelle l'un inclut l'héritage par défaut et l'autre non a déjà été mentionnée par Mucker - c'est "l'efficacité". Faire glisser et déposer des fichiers dans un volume ne fait que modifier l'entrée Index - les fichiers ne sont pas déplacés et leurs informations ACL sont laissées seules. Fait pour une opération simple. Cependant, lorsque des fichiers sont déplacés sur des volumes, les fichiers et leurs listes de contrôle d' accès doivent être redéfinis, il est donc judicieux de le faire correctement et d'inclure l'héritage, car cela n'entraîne pas de surcharge évitable.

Je ne comprends pas pourquoi Microsoft ne résout pas ce problème. Serait-il trop difficile d'inclure une boîte de dialogue dans le cadre du glisser-déposer d'Explorer? Quelque chose comme "Vous avez déplacé des fichiers vers un emplacement avec des droits d'accès différents, souhaitez-vous hériter des autorisations du nouveau dossier parent? O ou N?"

Cordialement, Stonegiant