17Aug
Lorsque vous utilisez Linux et OS X, le système d'exploitation ne vous empêchera pas de supprimer un fichier actuellement utilisé sous Windows, il vous sera expressément interdit de le faire. Ce qui donne? Pourquoi pouvez-vous modifier et supprimer les fichiers en cours d'utilisation sur les systèmes dérivés d'Unix, mais pas sur Windows?
Question d'aujourd'hui &La session de réponse nous est offerte par SuperUser, une subdivision de Stack Exchange, un regroupement communautaire de sites Web Q & A.
La question
SuperUser lecteur the.midget veut savoir pourquoi Linux et Windows traitent les fichiers en cours d'utilisation différemment:
Une des choses qui m'a intrigué depuis que j'ai commencé à utiliser Linux est le fait qu'il vous permet de changer le nom deun fichier ou même le supprimer pendant sa lecture. Un exemple est comment j'ai accidentellement essayé de supprimer une vidéo pendant qu'elle jouait. J'ai réussi, et j'ai été surpris quand j'ai appris que vous pouviez changer à peu près n'importe quoi dans un fichier sans vous préoccuper de savoir s'il est utilisé pour le moment ou non.
Alors, que se passe-t-il dans les coulisses et l'empêche-t-il de supprimer arbitrairement des choses dans Windows comme il le peut sous Linux?
Les contributeurs Réponse
SuperUser ont fait la lumière sur la situation de the.midget.Étonné écrit:
Chaque fois que vous ouvrez ou exécutez un fichier dans Windows, Windows verrouille le fichier en place( simplification, mais généralement vrai). 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 qu'il prenne effet.
D'autre part, les systèmes d'exploitation de type Unix comme Linux et Mac OS X ne verrouillent pas le fichier mais plutôt 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 le programme qui a déjà le fichier ouvert. Ainsi, vous pouvez supprimer un fichier pendant qu'il est encore en cours d'exécution et qu'il continue à exister sur le disque tant que certains processus ont un handle ouvert même si son entrée dans la table de 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 par défaut à un verrouillage de fichier automatique et obligatoire. UNIXes par défaut pour le verrouillage de fichier manuel, 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 code de Windows utilise 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 "en conflit".Si vous ouvrez un fichier en écriture, les écritures sont supposées être en conflit, même si vous n'écrivez jamais dans le fichier. Idem pour renommer.
Et, voilà où ça empire. Autre que l'ouverture pour lire ou écrire, 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 n'importe quelle opération légale. Puisque le verrouillage est obligatoire, une ouverture qui autorise une opération en conflit sera refusée, même si le code n'a jamais eu l'intention d'effectuer l'opération en conflit mais qu'il ouvrait simplement le fichier à d'autres fins.
Donc, si le code utilise l'API C / C ++, ou utilise l'API native sans penser spécifiquement à ces problèmes, ils finiront par empêcher le maximum d'opérations possibles pour chaque fichier qu'ils ouvrent et ne pourront pas ouvrir un fichier saufils pourraient effectuer sur lui une fois ouvert est non conflictuel.
A mon avis, la méthode Windows fonctionnerait beaucoup mieux que la méthode UNIX si chaque programme choisissait ses modes de partage et les modes ouverts de manière sagement et correctement gérée. La méthode UNIX, cependant, fonctionne mieux si le code ne prend pas la peine de penser à ces problèmes. Malheureusement, l'API C / C ++ de base ne correspond pas bien à l'API du 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.
Là vous l'avez: deux approches différentes de la gestion des fichiers donnent deux résultats différents.
Avoir quelque chose à ajouter à l'explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d'autres utilisateurs de Stack Exchange? Découvrez le fil de discussion complet ici.
