Pourquoi ne puis-je pas modifier les fichiers en cours d'utilisation sous Windows comme je le peux sous Linux et OS X?

Lorsque vous utilisez Linux et OS X, le système d’exploitation ne vous empêche pas de supprimer un fichier en cours d’utilisation, mais il vous sera expressément interdit de le faire sous Windows. Ce qui donne? Pourquoi pouvez-vous éditer et supprimer des fichiers en cours d’utilisation sur des systèmes dérivés d’Unix mais pas sous Windows??

La séance de questions et réponses d'aujourd'hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté..

La question

Le lecteur superutilisateur the.midget veut savoir pourquoi Linux et Windows traitent les fichiers en cours d’utilisation différemment:

Une des choses qui me laisse perplexe depuis que je commence à utiliser Linux est le fait qu’elle vous permet de changer le nom d’un fichier, voire de le supprimer en cours de lecture. Un exemple est la façon dont j'ai accidentellement essayé de supprimer une vidéo en cours de lecture. J'ai réussi et j'ai été surpris d'apprendre que vous pouvez modifier à peu près n'importe quoi dans un fichier sans vous soucier de son utilisation actuelle ou non..

Donc, que se passe-t-il dans les coulisses et l'empêche de supprimer des éléments dans Windows comme il le peut dans Linux?

La réponse

Les contributeurs SuperUser ont jeté un peu de lumière sur la situation pour le.midget. Amazed écrit:

Chaque fois que vous ouvrez ou exécutez un fichier dans Windows, Windows le verrouille (c'est une simplification, mais généralement la valeur true.) Un fichier verrouillé par un processus ne peut pas être supprimé tant que ce processus ne l'a pas libéré. C’est pourquoi chaque fois que Windows doit se mettre à jour, vous avez besoin d’un redémarrage pour que cela prenne effet..

D'autre part, les systèmes d'exploitation de type Unix tels que Linux et Mac OS X ne verrouillent pas le fichier mais les secteurs de disque sous-jacents. Cela peut sembler une différenciation triviale, mais cela signifie que l'enregistrement du fichier dans la table des matières du système de fichiers peut être supprimé sans perturber tout programme ayant déjà ouvert le fichier. Ainsi, vous pouvez supprimer un fichier en cours d’exécution ou d’exploitation, et il continuera d’exister sur le disque tant qu’un processus aura un descripteur ouvert, même si son entrée dans la table des fichiers a disparu..

David Schwartz développe l'idée et souligne comment les choses devraient être idéalement et comment elles sont en pratique:

Windows utilise par défaut le verrouillage automatique et obligatoire des fichiers. UNIXes est réglé par défaut sur le verrouillage manuel de fichiers coopératif. Dans les deux cas, les valeurs par défaut peuvent être remplacées, mais dans les deux cas, elles ne le sont généralement pas..

Beaucoup de vieux codes Windows utilisent l'API C / C ++ (fonctions comme fopen) plutôt que l'API native (fonctions comme CreateFile). L'API C / C ++ ne vous donne aucun moyen de spécifier le fonctionnement du verrouillage obligatoire. Vous obtenez donc les valeurs par défaut. Le «mode de partage» par défaut tend à interdire les opérations «conflictuelles». Si vous ouvrez un fichier en écriture, les écritures sont supposées entrer en conflit, même si vous n'écrivez jamais dans le fichier. Idem pour renommer.

Et voici où ça empire. À part l'ouverture en lecture ou en écriture, l'API C / C ++ ne fournit aucun moyen de spécifier ce que vous avez l'intention de faire avec le fichier. L’API doit donc supposer que vous allez effectuer toute opération légale. Étant donné que le verrouillage est obligatoire, une ouverture autorisant une opération en conflit sera refusée, même si le code n'a jamais eu l'intention d'exécuter l'opération en conflit mais ouvrait simplement le fichier dans un autre but..

Ainsi, si le code utilise l'API C / C ++, ou utilise l'API native sans réfléchir spécifiquement à ces problèmes, ils empêcheront le plus grand nombre possible d'opérations possibles pour chaque fichier ouvert et ne pourront pas l'ouvrir, à moins que chaque opération possible ne soit possible. pourrait jouer sur une fois ouvert est inconcevable.

À mon avis, la méthode Windows fonctionnerait beaucoup mieux que la méthode UNIX si chaque programme choisissait ses modes de partage et ses modes ouverts de manière judicieuse et rationnelle. La méthode UNIX, cependant, fonctionne mieux si le code ne se donne pas la peine de réfléchir à ces problèmes. Malheureusement, l'API C / C ++ de base ne correspond pas bien à l'API de fichier Windows d'une manière qui gère les modes de partage et les conflits s'ouvrent bien. Donc, le résultat net est un peu brouillon.

Voilà: deux approches différentes de la gestion des fichiers donnent deux résultats différents.

Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.