Lorsque vous utilisez Linux et OS X, le système d’exploitation ne vous empêchera pas de supprimer un fichier actuellement utilisé, mais sous Windows, vous serez expressément interdit de le faire. Ce qui donne? Pourquoi pouvez-vous modifier et supprimer des fichiers en cours d’utilisation sur des systèmes dérivés d’Unix mais pas sous Windows?
La question
Lecteur SuperUser the.midget veut savoir pourquoi Linux et Windows traitent différemment les fichiers en cours d’utilisation:
L’une des choses qui m’interroge depuis que j’ai commencé à utiliser Linux est le fait que cela vous permet de changer le nom d’un fichier ou même de le supprimer pendant sa lecture. Un exemple est la façon dont j’ai accidentellement essayé de supprimer une vidéo pendant sa 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 savoir s’il est utilisé ou non pour le moment.
Alors, que se passe-t-il dans les coulisses et l’empêche-t-il de supprimer des éléments de Windows comme il le peut sous Linux?
La réponse
Les contributeurs de SuperUser ont fait la lumière sur la situation du.midget. Amazed écrit:
Chaque fois que vous ouvrez ou exécutez un fichier dans Windows, Windows verrouille le fichier en place (c’est une simplification, mais généralement vrai.) Un fichier qui est verrouillé par un processus ne peut pas être supprimé tant que ce processus ne le libère pas. C’est pourquoi chaque fois que Windows doit se mettre à jour, vous avez besoin d’un redémarrage pour qu’il prenne effet.
D’un autre côté, 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 déranger les programmes qui ont déjà le fichier ouvert. Ainsi, vous pouvez supprimer un fichier pendant qu’il est encore en cours d’exécution ou en cours d’utilisation et il continuera d’exister sur le disque tant qu’un processus a un handle ouvert pour lui 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 dans la pratique:
Windows utilise par défaut le verrouillage de fichier automatique et obligatoire. UNIX utilise par défaut le verrouillage de fichier manuel et 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.
Un grand nombre d’anciens codes Windows utilisent l’API C / C ++ (des fonctions comme fopen) plutôt que l’API native (des 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 a tendance à interdire les opérations «conflictuelles». Si vous ouvrez un fichier pour l’écriture, les écritures sont supposées être en conflit, même si vous n’écrivez jamais réellement dans le fichier. Idem pour les renommés.
Et c’est là que ça empire. En dehors de 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. Puisque le verrouillage est obligatoire, une ouverture qui autorise une opération conflictuelle sera refusée, même si le code n’a jamais eu l’intention d’effectuer l’opération conflictuelle mais ouvrait simplement le fichier dans un autre but.
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 l’ensemble maximal d’opérations possibles pour chaque fichier qu’ils ouvrent et ne pourront pas ouvrir un fichier à moins que chaque opération possible pourrait jouer dessus une fois ouvert est sans conflit.
À mon avis, la méthode Windows fonctionnerait beaucoup mieux que la méthode UNIX si chaque programme choisissait ses modes de partage et ouvrait les modes de manière judicieuse et gérée de manière saine. La méthode UNIX, cependant, fonctionne mieux si le code ne prend pas la peine de réfléchir à ces problèmes. Malheureusement, l’API de base C / C ++ ne correspond pas bien à l’API de fichier Windows d’une manière qui gère bien les modes de partage et les conflits ouverts. Le résultat net est donc un peu compliqué.
Voilà: deux approches différentes de la gestion des fichiers donnent deux résultats différents.
Avez-vous quelque chose à ajouter à l’explication? Sonnez dans les commentaires. Vous voulez lire plus de réponses d’autres utilisateurs de Stack Exchange férus de technologie? Check-out le fil de discussion complet ici.
