Calculer Girl
  1. Calculer Girl
  3. Sur quels systèmes / systèmes de fichiers os.open () atomic est-il?
Intereting Posts
Impossible d’importer _winreg dans l’environnement virtuel Python 2.7.9 Programme Java Swing Run au démarrage de Windows Messages WM_TIMER supprimés lorsque vous cliquez et maintenez le bouton de la souris enfoncé sur le bouton X de Windows Notepad ++ remplacement Comment éviter la collision de noms avec les macros définies dans les fichiers d’en-tête Windows? Dirigez plusieurs domaines vers un seul ensemble de fichiers PHP? Exécuter un script sur plusieurs fichiers sous Unix Comment vérifier si POSL ACL est activé pour un chemin donné Ecrire un script pour répondre aux invites avec le texte spécifié Comment capturer toutes les commandes saisies sous Unix / Linux par n’importe quel utilisateur? Charger un fichier PHP dans Chrome affiche les codes PHP L’émulateur Android ne fonctionne pas sur Ubuntu 16.10 capistrano 3 deploy: erreur de nettoyage des anciennes versions propres Où se trouve le fichier DB_CONFIG de la firebase database Berkeley situé dans Unix? Où déployer l’application symfony2

Sur quels systèmes / systèmes de fichiers os.open () atomic est-il?

Cet article stipule que 

fd = os.open('foo.lock', os.O_CREAT|os.O_EXCL|os.O_RDWR)

“est atomique sur la plupart des systèmes de fichiers“. Est-ce vrai (sous Unix et Windows)? Sur quels systèmes de fichiers?

Les documents indiquent que les indicateurs mentionnés sont disponibles sous Unix et Windows. Par conséquent, cela ressemble à une méthode inter-plateforme tentante pour le locking des fichiers (les indicateurs O_CREAT et O_EXCL garantissent que le processus appelant crée le fichier).

Pour les systèmes compatibles UN * X (certifiés POSIX / IEEE 1003.1 selon OpenGroup), le comportement est garanti lorsque les spécifications OpenGroups pour open(2) requièrent . Citation:

O_EXCL
Si O_CREAT et O_EXCL sont définis, open () doit échouer si le fichier existe. La vérification de l’existence du fichier et la création du fichier s’il n’existe pas doivent être atomiques par rapport aux autres threads exécutant open () en nommant le même nom de fichier dans le même répertoire avec O_EXCL et O_CREAT. Si O_EXCL et O_CREAT sont définis, et que le chemin indique un lien symbolique, open () doit échouer et définir errno avec [EEXIST], quel que soit le contenu du lien symbolique. Si O_EXCL est défini et que O_CREAT n’est pas défini, le résultat n’est pas défini.

Les systèmes “communs” de type UN * X et UN * X (Linux, MacOSX, * BSD, Solaris, AIX, HP / UX) se comportent certainement comme cela.

L’API Windows n’ayant pas open() tant que tel, la fonction de bibliothèque y est nécessairement réimplémentée en termes d’API native mais il est possible de conserver la sémantique.

Je ne sais pas quels systèmes largement utilisés ne seraient pas conformes. QNX, même s’il n’est pas certifié POSIX, a la même instruction dans ses documents pour open() . Les pages de manuel * BSD ne mentionnent pas explicitement “l’atomicité” mais Free / Net / OpenBSD l’implémente. Même les exotiques comme SymbianOS (qui, comme Windows, n’ont pas d’appel de système open UN * X-ish) peuvent faire l’ouverture / la création atomique.

Pour des résultats plus intéressants, essayez de trouver une bibliothèque d’exécution de système d’exploitation / C qui a open() mais n’implémente pas la sémantique ci-dessus… et sur laquelle Python fonctionnerait avec des threads (vous y êtes, MSDOS…). ).

Edit: Mon article se concentre particulièrement sur “quels systèmes d’exploitation ont cette caractéristique pour open ?” – pour laquelle la réponse est “à peu près tous”. Wrt. pour les systèmes de fichiers, cependant, l’image est différente car les systèmes de fichiers réseau – NFS, SMB / CIFS ou autres – ne O_EXCL pas toujours O_EXCL car cela pourrait entraîner un déni de service (si un client effectue un open(..., O_EXCL, ...) et arrête tout simplement de parler avec le serveur de fichiers / est arrêté, tout le monde serait verrouillé).