La séance de questions-réponses d'aujourd'hui nous est offerte par la sous-division SuperUser 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:
One of the things that has puzzled me ever since I started using Linux is the fact that it allows you to change the name of a file or even delete it while it is being read. An example is how I accidentally tried to delete a video while it was playing. I succeeded, and was surprised as I learnt that you can change just about anything in a file without caring if it’s being used at the moment or not.
Alors, que se passe-t-il dans les coulisses et l'empêche de supprimer des éléments dans Windows comme il le peut sous 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 verrouille le fichier (il s'agit d'une simplification, mais généralement de 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 devez redémarrer pour que celle-ci 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 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 les programmes ayant déjà ouvert le fichier. Vous pouvez donc supprimer un fichier en cours d’exécution ou d’exploitation, et il continuera d’exister sur le disque tant que le 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 defaults to automatic, mandatory file locking. UNIXes default to manual, cooperative file locking. In both cases, the defaults can be overriden, but in both cases they usually aren’t.
A lot of old Windows code uses the C/C++ API (functions like fopen) rather than the native API (functions like CreateFile). The C/C++ API gives you no way to specify how mandatory locking will work, so you get the defaults. The default “share mode” tends to prohibit “conflicting” operations. If you open a file for writing, writes are assumed to conflict, even if you never actually write to the file. Ditto for renames.
And, here’s where it gets worse. Other than opening for read or write, the C/C++ API provides no way to specify what you intend to do with the file. So the API has to assume you are going to perform any legal operation. Since the locking is mandatory, an open that allows a conflicting operation will be refused, even if the code never intended to perform the conflicting operation but was just opening the file for another purpose.
So if code uses the C/C++ API, or uses the native API without specifically thinking about these issues, they will wind up preventing the maximum set of possible operations for every file they open and being unable to open a file unless every possible operation they could perform on it once opened is unconflicted.
In my opinion, the Windows method would work much better than the UNIX method if every program chose its share modes and open modes wisely and sanely handled failure cases. The UNIX method, however, works better if code doesn’t bother to think about these issues. Unfortunately, the basic C/C++ API doesn’t map well onto the Windows file API in a way that handles share modes and conflicting opens well. So the net result is a bit messy.
Voilà, deux méthodes différentes de traitement 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.
