Verrouillage de fichiers - File locking

Le verrouillage de fichier est un mécanisme qui restreint l'accès à un fichier informatique , ou à une région d'un fichier, en permettant à un seul utilisateur ou processus de le modifier ou de le supprimer à un moment précis et d'empêcher la lecture du fichier pendant qu'il est modifié ou supprimé .

Les systèmes implémentent le verrouillage pour empêcher le scénario classique de mise à jour par intercession , qui est un exemple typique d'une condition de concurrence , en appliquant la sérialisation des processus de mise à jour à n'importe quel fichier donné. L'exemple suivant illustre le problème de mise à jour intermédiaire :

  1. Le processus A lit un enregistrement client à partir d'un fichier contenant des informations sur le compte, y compris le solde du compte et le numéro de téléphone du client.
  2. Le processus B lit maintenant le même enregistrement à partir du même fichier, il a donc sa propre copie.
  3. Le processus A modifie le solde du compte dans sa copie de l'enregistrement client et réécrit l'enregistrement dans le fichier.
  4. Le processus B, qui a toujours la valeur périmée d' origine pour le solde du compte dans sa copie de l'enregistrement client, met à jour le solde du compte et réécrit l'enregistrement client dans le fichier.
  5. Le processus B a maintenant écrit sa valeur de solde de compte périmé dans le fichier, entraînant la perte des modifications apportées par le processus A.

La plupart des systèmes d'exploitation prennent en charge le concept de verrouillage d'enregistrement , ce qui signifie que des enregistrements individuels dans un fichier donné peuvent être verrouillés, augmentant ainsi le nombre de processus de mise à jour simultanés . La maintenance de la base de données utilise le verrouillage de fichier, ce qui permet de sérialiser l'accès à l'intégralité du fichier physique sous-jacent à une base de données. Bien que cela empêche tout autre processus d'accéder au fichier, cela peut être plus efficace que de verrouiller individuellement de nombreuses régions du fichier en supprimant la surcharge d'acquisition et de libération de chaque verrou.

Une mauvaise utilisation des verrous de fichiers, comme tout verrou d' ordinateur , peut entraîner des performances médiocres ou des blocages . Le verrouillage de fichiers peut également faire référence à une sécurité supplémentaire appliquée par un utilisateur d'ordinateur en utilisant la sécurité Windows, les autorisations NTFS ou en installant un logiciel de verrouillage de fichiers tiers.

Dans les mainframes

IBM a été le pionnier du verrouillage de fichiers en 1963 pour une utilisation dans les ordinateurs centraux utilisant OS/360 , où il a été appelé "contrôle exclusif".

Dans Microsoft Windows

Microsoft Windows utilise trois mécanismes distincts pour gérer l'accès aux fichiers partagés :

  1. en utilisant des contrôles d'accès au partage qui permettent aux applications de spécifier le partage d'accès au fichier entier pour la lecture, l'écriture ou la suppression
  2. utiliser des verrous de plage d'octets pour arbitrer l'accès en lecture et en écriture aux régions dans un seul fichier
  3. par les systèmes de fichiers Windows interdisant aux fichiers d'exécution d'être ouverts pour un accès en écriture ou en suppression

Windows hérite de la sémantique des contrôles d'accès au partage du système MS-DOS , où le partage a été introduit dans MS-DOS 3.3 . Ainsi, une application doit explicitement autoriser le partage lorsqu'elle ouvre un fichier ; sinon, il dispose d'un accès exclusif en lecture, écriture et suppression au fichier jusqu'à sa fermeture (d'autres types d'accès, tels que ceux pour récupérer les attributs d'un fichier sont autorisés.)

Pour un fichier ouvert avec un accès partagé, les applications peuvent alors utiliser le verrouillage de plage d'octets pour contrôler l'accès à des régions spécifiques du fichier. De tels verrous de plage d'octets spécifient une région du fichier (décalage et longueur) et le type de verrou (partagé ou exclusif). Notez qu'il n'est pas nécessaire que la région du fichier à verrouiller contienne des données dans le fichier, et les applications exploitent parfois cette capacité pour implémenter leurs fonctionnalités.

Pour les applications qui utilisent les API de lecture/écriture de fichiers dans Windows, des verrous de plage d'octets sont appliqués (également appelés verrous obligatoires ) par les systèmes de fichiers qui s'exécutent dans Windows. Pour les applications qui utilisent les API de mappage de fichiers dans Windows, les verrous de plage d'octets ne sont pas appliqués (également appelés verrous consultatifs. ) Le verrouillage de plage d'octets peut également avoir d'autres effets secondaires sur le système Windows. Par exemple, le mécanisme de partage de fichiers Windows désactivera généralement la mise en cache côté client d'un fichier pour tous les clients lorsque des verrous de plage d'octets sont utilisés par un client. Le client observera un accès plus lent car les opérations de lecture et d'écriture doivent être envoyées au serveur sur lequel le fichier est stocké.

Une gestion incorrecte des erreurs dans un programme d'application peut conduire à un scénario dans lequel un fichier est verrouillé (soit en utilisant un accès « partage » soit avec un verrouillage de fichier par plage d'octets) et ne peut pas être consulté par d'autres applications. Si tel est le cas, l'utilisateur peut être en mesure de restaurer l'accès aux fichiers en arrêtant manuellement le programme défectueux. Cela se fait généralement via l' utilitaire Gestionnaire des tâches .

Le paramètre de mode de partage (dwShareMode) de la CreateFilefonction (utilisé pour ouvrir des fichiers) détermine le partage de fichiers. Le mode de partage peut être spécifié pour permettre le partage du fichier pour un accès en lecture, écriture ou suppression, ou toute combinaison de ceux-ci. Les tentatives ultérieures d'ouverture du fichier doivent être compatibles avec tous les accès de partage précédemment accordés au fichier. Lorsque le fichier est fermé, les restrictions d'accès au partage sont ajustées pour supprimer les restrictions imposées par ce fichier spécifique ouvert.

Le type de verrouillage de plage d'octets est déterminé par le dwFlagsparamètre de la LockFileExfonction utilisée pour verrouiller une région d'un fichier. La fonction API WindowsLockFile peut également être utilisée et acquiert un verrou exclusif sur la région du fichier.

Tout fichier contenant un fichier de programme exécutable qui est actuellement en cours d' exécution sur le système informatique en tant que programme (par exemple un EXE, COM, DLL, CPLou un autre format de fichier binaire de programme) est normalement verrouillée par le système d'exploitation lui - même, ce qui empêche toute demande de modification ou de suppression. Toute tentative de le faire sera refusée avec une erreur de violation de partage, malgré le fait que le fichier programme n'est ouvert par aucune application. Cependant, certains accès sont toujours autorisés. Par exemple, un fichier d'application en cours d'exécution peut être renommé ou copié (lu) même lors de l'exécution.

Les fichiers sont accessibles par les applications dans Windows à l'aide de descripteurs de fichiers . Ces descripteurs de fichiers peuvent être explorés avec l' utilitaire Process Explorer . Cet utilitaire peut également être utilisé pour forcer la fermeture des handles sans avoir besoin de terminer l'application qui les contient. Cela peut provoquer un comportement indéfini, car le programme recevra une erreur inattendue lors de l'utilisation du handle à fermeture forcée et peut même fonctionner sur un fichier inattendu puisque le numéro de handle peut être recyclé.

Les éditions Microsoft Windows XP et Server 2003 ont introduit la capacité d' instantané de volume ( VSS) dans NTFS , permettant aux fichiers ouverts d'être accessibles par un logiciel de sauvegarde malgré les verrous exclusifs. Cependant, à moins que le logiciel ne soit réécrit pour prendre spécifiquement en charge cette fonctionnalité, l'instantané sera uniquement cohérent en cas de panne , tandis que les applications correctement prises en charge peuvent aider le système d'exploitation à créer des instantanés « cohérents sur le plan transactionnel ». D'autres logiciels commerciaux pour accéder aux fichiers verrouillés sous Windows incluent File Access Manager et Open File Manager . Ceux-ci fonctionnent en installant leurs propres pilotes pour accéder aux fichiers en mode noyau .

Dans les systèmes de type Unix

Les systèmes d' exploitation de type Unix (y compris Linux et macOS d'Apple ) ne verrouillent normalement pas automatiquement les fichiers ouverts. Plusieurs types de mécanismes de verrouillage de fichiers sont disponibles dans différentes versions d'Unix, et de nombreux systèmes d'exploitation prennent en charge plus d'un type pour la compatibilité. Le mécanisme le plus courant est fcntl. Deux autres mécanismes de ce type sont flock(2)et lockf(3), qui peuvent être séparés ou peuvent être mis en œuvre au sommet fcntl. Bien que certains types de verrous puissent être configurés pour être obligatoires, les verrous de fichiers sous Unix sont par défaut consultatifs . Cela signifie que les processus coopérants peuvent utiliser des verrous pour coordonner l'accès à un fichier entre eux, mais les processus non coopératifs sont également libres d'ignorer les verrous et d'accéder au fichier de la manière qu'ils choisissent. En d'autres termes, les verrous de fichiers verrouillent uniquement les autres verrous de fichiers, pas les E/S.

Deux types de serrures sont proposés : les serrures partagées et les serrures exclusives. Dans le cas de fcntl, différents types de verrous peuvent être appliqués à différentes sections (plages d'octets) d'un fichier, ou bien à l'ensemble du fichier. Les verrous partagés peuvent être détenus par plusieurs processus en même temps, mais un verrou exclusif ne peut être détenu que par un seul processus et ne peut pas coexister avec un verrou partagé. Pour acquérir un verrou partagé, un processus doit attendre qu'aucun processus ne détienne de verrou exclusif. Pour acquérir un verrou exclusif, un processus doit attendre qu'aucun processus ne détienne l'un ou l'autre type de verrou. Contrairement aux verrous créés par fcntl, ceux créés par flocksont conservés dans forks, ce qui les rend utiles pour forker des serveurs. Il est donc possible que plusieurs processus détiennent un verrou exclusif sur le même fichier, à condition que ces processus partagent une relation filiale et que le verrou exclusif ait été initialement créé dans un seul processus avant d'être dupliqué sur un fichier fork.

Les verrous partagés sont parfois appelés " verrous en lecture " et les verrous exclusifs sont parfois appelés " verrous en écriture ". Cependant, comme les verrous sur Unix sont consultatifs, cela n'est pas appliqué. Ainsi, il est possible pour une base de données d'avoir un concept d'« écritures partagées » par rapport aux « écritures exclusives » ; par exemple, la modification d'un champ en place peut être autorisée dans le cadre d'un accès partagé, tandis que la récupération de place et la réécriture de la base de données peuvent nécessiter un accès exclusif.

Les verrous de fichiers s'appliquent au fichier réel plutôt qu'au nom du fichier. Ceci est important car Unix permet à plusieurs noms de faire référence au même fichier. Avec le verrouillage non obligatoire, cela conduit à une grande flexibilité dans l'accès aux fichiers à partir de plusieurs processus. D'un autre côté, l'approche de verrouillage coopératif peut entraîner des problèmes lorsqu'un processus écrit dans un fichier sans obéir aux verrous de fichier définis par d'autres processus.

Pour cette raison, certains systèmes d'exploitation de type Unix offrent également une prise en charge limitée du verrouillage obligatoire . Sur de tels systèmes, un fichier dont le setgidbit est activé mais dont le bit d'exécution de groupe est désactivé lorsque ce fichier est ouvert sera soumis à un verrouillage obligatoire automatique si le système de fichiers sous-jacent le prend en charge. Cependant, les partitions NFS non locales ont tendance à ignorer ce bit. Si un fichier est soumis à un verrouillage obligatoire, les tentatives de lecture à partir d'une région verrouillée par un verrou exclusif ou d'écriture dans une région verrouillée par un verrou partagé ou exclusif seront bloquées jusqu'à ce que le verrou soit libéré. Cette stratégie a d'abord trouvé son origine dans System V, et se retrouve aujourd'hui dans les systèmes d'exploitation Solaris , HP-UX et Linux. Cependant, il ne fait pas partie de POSIX et les systèmes d'exploitation dérivés de BSD tels que FreeBSD , OpenBSD , NetBSD et macOS d'Apple ne le prennent pas en charge. Linux prend également en charge le verrouillage obligatoire via le -o mandparamètre spécial pour le montage du système de fichiers ( mount(8)), mais celui-ci est rarement utilisé.

Certains systèmes d'exploitation de type Unix empêchent les tentatives d'ouverture du fichier exécutable d'un programme en cours d'exécution pour l'écriture ; il s'agit d'une troisième forme de verrouillage, distincte de celles fournies par fcntlet flock.

Problèmes

Plusieurs processus peuvent détenir une exclusivité flocksur un fichier donné si le verrou exclusif a été dupliqué dans un fichier fork. Cela simplifie le codage des serveurs réseau et aide à éviter les conditions de concurrence, mais peut être déroutant pour les non-conscients.

Les verrous obligatoires n'ont aucun effet sur l' unlinkappel système. Par conséquent, certains programmes peuvent effectivement contourner le verrouillage obligatoire. Stevens & Rago (2005) ont observé que l' edéditeur a effectivement fait cela.

Si et comment les flockverrous fonctionnent sur les systèmes de fichiers réseau, tels que NFS , dépend de l'implémentation. Sur les systèmes BSD , les flockappels sur un descripteur de fichier ouvert à un fichier sur une partition montée sur NFS sont des no-ops réussis . Sous Linux antérieur à 2.6.12, les flockappels sur les fichiers NFS n'agiraient que localement. Le noyau 2.6.12 et les versions ultérieures implémentent les flockappels sur les fichiers NFS à l'aide des verrous de plage d'octets POSIX. Ces verrous seront visibles pour les autres clients NFS qui implémentent des verrous POSIX defcntl style , mais invisibles pour ceux qui ne le font pas.

Les mises à niveau et les rétrogradations de verrou libèrent l'ancien verrou avant d'appliquer le nouveau verrou. Si une application rétrograde un verrou exclusif en verrou partagé alors qu'une autre application est bloquée en attente d'un verrou exclusif, cette dernière application peut obtenir le verrou exclusif et verrouiller la première application. Cela signifie que les rétrogradations de verrouillage peuvent bloquer, ce qui peut être contre-intuitif.

Tous fcntl les verrous associés à un fichier pour un processus donné sont supprimés lorsque tout descripteur de fichier pour ce fichier est fermé par ce processus, même si un verrou n'a jamais été demandé pour ce descripteur de fichier. De plus, les fcntlverrous ne sont pas hérités par un processus enfant. La fcntlsémantique proche est particulièrement gênante pour les applications qui appellent des bibliothèques de sous-programmes pouvant accéder aux fichiers. Aucun de ces "bugs" ne se produit en utilisant des flockverrous de style réel .

La préservation du statut de verrouillage sur les descripteurs de fichiers ouverts transmis à un autre processus à l'aide d'un socket de domaine Unix dépend de l'implémentation.

Problèmes d'E/S tamponnées

Une source d'échec de verrouillage se produit lorsque les E/S mises en mémoire tampon ont des mémoires tampon affectées dans l'espace de travail local de l'utilisateur, plutôt que dans un pool de mémoire tampon du système d'exploitation. freadet fwritesont couramment utilisés pour effectuer des E/S tamponnées, et une fois qu'une section d'un fichier est lue, une autre tentative de lecture de cette même section obtiendra très probablement les données du tampon local. Le problème est qu'un autre utilisateur attaché au même fichier a ses propres tampons locaux, et la même chose se produit pour eux. Une fwritedes données obtenues à partir du tampon par freadn'obtiendra pas les données du fichier lui-même, et un autre utilisateur aurait pu les modifier. Les deux pourraient être utilisés flockpour un accès exclusif, ce qui empêche les écritures simultanées, mais comme les lectures lisent à partir du tampon et non du fichier lui-même, toutes les données modifiées par l'utilisateur n°1 peuvent être perdues par l'utilisateur n°2 (écrasées). La meilleure solution à ce problème consiste à utiliser des E/S sans tampon ( readet write) avec flock, ce qui signifie également utiliser à la lseekplace de fseeket ftell. Bien sûr, vous devrez effectuer des ajustements pour les paramètres de fonction et les résultats renvoyés. De manière générale, les E/S mises en mémoire tampon sont dangereuses lorsqu'elles sont utilisées avec des fichiers partagés.

Dans AmigaOS

Dans AmigaOS , un verrou sur un fichier (ou un répertoire) peut être acquis en utilisant la Lockfonction (dans le dos.library). Un verrou peut être partagé (d'autres processus peuvent lire le fichier/répertoire, mais ne peuvent ni le modifier ni le supprimer), ou exclusif afin que seul le processus qui réussit à acquérir le verrou puisse accéder ou modifier l'objet. Le verrou est sur l'ensemble de l'objet et non sur une partie de celui-ci. Le verrou doit être libéré avec la UnLockfonction : contrairement à Unix, le système d'exploitation ne déverrouille pas implicitement l'objet lorsque le processus se termine.

Verrouiller les fichiers

Les scripts shell et autres programmes utilisent souvent une stratégie similaire à l'utilisation du verrouillage de fichiers : création de fichiers de verrouillage , qui sont des fichiers dont le contenu n'est pas pertinent (bien que souvent on trouvera l' identifiant de processus du détenteur du verrou dans le fichier) et dont le seul but est de signaler par leur présence qu'une ressource est verrouillée. Un fichier de verrouillage est souvent la meilleure approche si la ressource à contrôler n'est pas du tout un fichier normal, donc l'utilisation de méthodes de verrouillage de fichiers ne s'applique pas. Par exemple, un fichier de verrouillage peut régir l'accès à un ensemble de ressources associées, telles que plusieurs fichiers, répertoires différents, un groupe de partitions de disque ou un accès sélectionné à des protocoles de niveau supérieur tels que des serveurs ou des connexions de base de données.

Lors de l'utilisation de fichiers de verrouillage, il faut veiller à ce que les opérations soient atomiques . Pour obtenir un verrou, le processus doit vérifier que le fichier de verrou n'existe pas puis le créer, tout en empêchant un autre processus de le créer entre-temps. Diverses méthodes pour ce faire incluent:

  • En utilisant la lockfilecommande (un créateur de fichier sémaphore conditionnel distribué dans le procmailpackage).
  • Appels système qui créent un fichier, mais échouent si le fichier existe déjà. (Les appels système sont disponibles à partir de langages tels que C ou C++, et les scripts shell peuvent utiliser noclobber )
  • Utilisation de la mkdircommande et vérification du code de sortie en cas d'échec

Les fichiers de verrouillage sont souvent nommés avec un tilde ( ~) préfixé au nom du fichier qu'ils verrouillent, ou un double du nom de fichier complet suivi du suffixe .LCK . S'ils verrouillent une ressource autre qu'un fichier, ils peuvent être nommés de manière plus arbitraire.

Certains produits Mozilla (tels que Firefox , Thunderbird, Sunbird) utilisent ce type de mécanisme de verrouillage des ressources de fichiers (à l'aide d'un fichier temporaire nommé "parent.lock".)

Logiciel de déblocage

Un outil de déverrouillage est un utilitaire utilisé pour déterminer quel processus verrouille un fichier et affiche une liste de processus ainsi que des choix sur ce qu'il faut faire avec le processus (tuer une tâche, déverrouiller, etc.) ainsi qu'une liste d'options de fichier telles que supprimer ou renommer. Sur certains systèmes de type Unix, des utilitaires tels que fstatet lockfpeuvent être utilisés pour inspecter l'état des verrous de fichiers par processus, par nom de fichier ou les deux.

Sur les systèmes Windows, si un fichier est verrouillé, il est possible de programmer son déplacement ou sa suppression à effectuer au prochain redémarrage. Cette approche est généralement utilisée par les installateurs pour remplacer les fichiers système verrouillés.

Systèmes de contrôle de version

Dans les systèmes de contrôle de version, le verrouillage de fichier est utilisé pour empêcher deux utilisateurs de modifier la même version de fichier en parallèle, puis lors de l'enregistrement, le deuxième utilisateur d'écraser ce que le premier utilisateur a modifié. Ceci est implémenté en marquant les fichiers verrouillés comme en lecture seule dans le système de fichiers. Un utilisateur souhaitant modifier le fichier effectue une opération de déverrouillage (également appelée extraction), et jusqu'à ce qu'une opération d'archivage (magasin) soit effectuée ou que le verrouillage soit rétabli, personne d'autre n'est autorisé à déverrouiller le fichier.

Voir également

Les références

Liens externes