Ouverture en lecture exclusive

Version imprimable

03/07/2020, 20h48
SybelleDeNuit

Ouverture en lecture exclusive

Bonjour,
Mon problème est peut-être simple mais je n'ai pas trouvé la réponse après un long temps de recherche.:arf:
Je cherche à ouvrir un fichier en LECTURE et pendant qu'il est ouvert, qu'aucun autre process puisse y accéder en lecture (et encore moins en écriture) avant qu'il ne soit fermé par le premier programme qui le lit. C'est navrant.

Suis-je une tarte ?
Quelle que soit la réponse à cette deuxième question, merci pour votre éclairage de ma faible lanterne.

Syb'
03/07/2020, 22h22
wiztricks

Salut,

Citation:

Envoyé par SybelleDeNuit

Quelle que soit la réponse à cette deuxième question, merci pour votre éclairage de ma faible lanterne.

Un fichier est un objet système.
Pour en verrouiller l'accès, il faut utiliser des méthodes systèmes.

Pour Linux, il y a la fonction fnctl.flock, pour windows ce sera msvcrt.locking.
Et vous avez aussi des bibliothèques externes qui cachent tout çà dans des fonctions indépendantes de la plateforme comme py-filelock.

- W

Citation:

Envoyé par wiztricks

Salut,

Un fichier est un objet système.
Pour en verrouiller l'accès, il faut utiliser des méthodes systèmes.

Pour Linux, il y a la fonction fnctl.flock, pour windows ce sera msvcrt.locking.
Et vous avez aussi des bibliothèques externes qui cachent tout çà dans des fonctions indépendantes de la plateforme comme py-filelock.

- W

Oooh! J'ai cherché longtemps aussi et Google ne m'a jamais parlé de ça !
edit : Euh Wiz msvcrt.locking empêche aussi la lecture ? J'ai fais des tests à partir de ça : https://effbot.org/librarybook/msvcr...t-example-3.py et j'ai pas l'impression que c'est ce mode de fonctionnement que souhaite SybelleDeNuit ???

Sybelle tu veux vraiment bloquer l'accès aux fichiers c'est ça ?

Moi je propose un truc plus "bizarre", en changeant les permissions du propriétaire, je ne sais pas si ça bloquera ton fichier pour d'autres process mais ça t'empêchera de l'ouvrir avec un autre logiciel...
Edit : En tout cas si tu fais un os.remove(fichier), ben le fichier disparaît totalement.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 import win32security as w32 import ntsecuritycon as con import getpass def access_rights_win(path,unauthorized): w_user, _, _ = w32.LookupAccountName("", getpass.getuser()) sd = w32.GetFileSecurity(path, w32.DACL_SECURITY_INFORMATION) dacl = sd.GetSecurityDescriptorDacl() if unauthorized: dacl.AddAccessDeniedAce(w32.ACL_REVISION, con.FILE_ALL_ACCESS, w_user) else: dacl.DeleteAce(0) dacl.AddAccessAllowedAce(w32.ACL_REVISION, con.GENERIC_ALL, w_user) sd.SetSecurityDescriptorDacl(1, dacl, 0) w32.SetFileSecurity(path, w32.DACL_SECURITY_INFORMATION, sd)

04/07/2020, 08h10
wiztricks

Salut,

Citation:

Envoyé par LeNarvalo

Oooh! J'ai cherché longtemps aussi et Google ne m'a jamais parlé de ça !
edit : Euh Wiz msvcrt.locking empêche aussi la lecture ? J'ai fais des tests à partir de ça : https://effbot.org/librarybook/msvcr...t-example-3.py et j'ai pas l'impression que c'est ce mode de fonctionnement que souhaite SybelleDeNuit ???

Pour trouver quelque chose sur Google, il faut déjà lui donner de bons mots clefs.
Ce qui suppose avoir une idée de ce qu'on cherche!

Sinon, oui çà fonctionne (mieux sur Windows que sur Linux d'ailleurs) mais py-filelock n'est plus maintenu, utilisez portalocker à la place.
note: si vous utilisez une fonctionnalité documentée pour.... et que vous n'arrivez pas à la faire fonctionner, est ce que çà ne marche pas ou est-ce que vous n'arrivez pas à la faire fonctionner?

- W
04/07/2020, 08h57
SybelleDeNuit

Merci pour vos réponses. Je vais voir comment les mettre en oeuvre.
Donc il n'existe pas un attribut simple à l'ouverture d'un fichier en lecture pour le rendre inaccessible momentanément aux autres programmes genre open(myfilename, "rx")... C'est curieux...
Voici la finalité de ma question :
Un fichier texte contient une liste de job à effectuer. Un de mes ordi en réseau (j'en ai 6) va lire ce fichier pour exécuter le premier travail. Il le supprime alors de la liste. Ainsi quand un autre ordi est disponible, il effectue la même opération de lecture/effacement sur le job qui est en tête de liste. Et ainsi de suite.
La seule chose que je risque, bien que ce ne me soit jamais arrivé, est que le second ordi lise le nom du job avant que le premier ait eu le temps de l'effacer de la liste. Dans ce cas il exécuterait lui aussi ce job, ce qui n'est pas grave en soi mais comme chacun des jobs peut prendre plus de 3 jours de calcul... C'est trois jour des perdus... Et il y en a un paquet à traitrer... D'autre part je ne peux pas changer l'ordre de ma liste efficacement, pour les mêmes raisons.
Il doit y a voir une chance sur 100 milliard que cela se produise, mais ça m´énerve de le savoir...

Bonne fin de semaine à tous.
Syb'

PS : je marquerai comme résolu dans quelques jours, le temps de vérifier la faisabilité et l'efficacité des solutions proposées.
04/07/2020, 09h35
wiztricks

Salut,

Le verrouillage de fichier se fait côté OS, si vous programmez sur des ordinateurs en réseau, çà va dépendre du "file system" qui permettra d'accéder aux fichiers "en réseau"...
Le plus simple est de passer par un "serveur" à qui on demande quoi faire (et qui pourra sérialiser les demandes et savoir à qui il a confié quoi).

- W
04/07/2020, 10h17
Sve@r

Bonjour

Citation:

Envoyé par SybelleDeNuit

Donc il n'existe pas un attribut simple à l'ouverture d'un fichier en lecture pour le rendre inaccessible momentanément aux autres programmes genre open(myfilename, "rx")... C'est curieux...

Personnellement je n'en trouve pas l'utilité. Quelle raison peut-on avoir de ne pas vouloir qu'un autre procesuss puisse lire un fichier censé être lisible par tous ???

Citation:

Envoyé par SybelleDeNuit

Voici la finalité de ma question :
Un fichier texte contient une liste de job à effectuer. Un de mes ordi en réseau (j'en ai 6) va lire ce fichier pour exécuter le premier travail. Il le supprime alors de la liste.

Ah là je comprends mieux. Mais dans ce cas, le fichier n'est pas ouvert en lecture mais en écriture et ça c'est quand-même totalement différent !!!

Citation:

Envoyé par SybelleDeNuit

La seule chose que je risque, bien que ce ne me soit jamais arrivé, est que le second ordi lise le nom du job avant que le premier ait eu le temps de l'effacer de la liste. Dans ce cas il exécuterait lui aussi ce job, ce qui n'est pas grave en soi mais comme chacun des jobs peut prendre plus de 3 jours de calcul... C'est trois jour des perdus... Et il y en a un paquet à traitrer... D'autre part je ne peux pas changer l'ordre de ma liste efficacement, pour les mêmes raisons.

Un ordi centralisateur. Il lit les jobs dans le fichier et les mémorise. Ensuite il distribue un job différent à chaque ordi qui vient le lui demander. Comme ça plus de souci de locks ou autres car c'est l'ordi centralisateur qui s'occupe de mettre à jour le fichier.
04/07/2020, 12h23
SybelleDeNuit

Merci pour votre intervention.

Citation:

Envoyé par Sve@r

Personnellement je n'en trouve pas l'utilité. Quelle raison peut-on avoir de ne pas vouloir qu'un autre procesuss puisse lire un fichier censé être lisible par tous ???

Ben... Qui peut le plus peux le moins... Et justement dans mon cas, cela serait bien utile qu'il ne soit pas accessible durant un court instant de traitement...

Citation:

Envoyé par Sve@r

Ah là je comprends mieux. Mais dans ce cas, le fichier n'est pas ouvert en lecture mais en écriture et ça c'est quand-même totalement différent !!!

Il est ouvert en lecture pour récupérer le nom du job, puis en écriture pour être modifié. C'est pendant ce temps de LECTURE que je veux le rendre inaccessible afin que le job ne soit pas fait 2 fois. Pendant la phase d'écriture je n'ai pas de problème, une boucle me permet de faire attendre l'ordinateur qui veut lire que le fichier soit à nouveau disponible.

Citation:

Envoyé par Sve@r

Un ordi centralisateur. Il lit les jobs dans le fichier et les mémorise. Ensuite il distribue un job différent à chaque ordi qui vient le lui demander. Comme ça plus de souci de locks ou autres car c'est l'ordi centralisateur qui s'occupe de mettre à jour le fichier.

J'ai oublié de dire que mes python étaient exécutés sur les différents ordi à l'intérieur d'applications (LightWave ou Poser dans mon cas). Il ne m'est donc pas possible de distribuer les jobs depuis un serveur. Ce sont les appli locales qui vont les chercher quand elles sont disponibles.
Il n'existe pas à ma connaissance de commande du genre «Lightwave, ouvre toi avec tel fichier et exécute ce script dans la foulée», quel que soit le langage.
04/07/2020, 13h24
wiztricks

Salut,

Citation:

Envoyé par SybelleDeNuit

Il ne m'est donc pas possible de distribuer les jobs depuis un serveur. Ce sont les appli locales qui vont les chercher quand elles sont disponibles.

A la place d'ouvrir et mettre à jour un fichier partagé, vous pouvez exécuter des requêtes vers un serveur (à écrire) et démarrer les traitements en fonction de ce qu'il répondra (de la même façon, c'est juste plus de lignes de code)...

- W

Citation:

n de mes ordi en réseau (j'en ai 6) va lire ce fichier pour exécuter le premier travail. Il le supprime alors de la liste. Ainsi quand un autre ordi est disponible, il effectue la même opération de lecture/effacement sur le job qui est en tête de liste. Et ainsi de suite.
La seule chose que je risque, bien que ce ne me soit jamais arrivé, est que le second ordi lise le nom du job avant que le premier ait eu le temps de l'effacer de la liste.

Vu de loin ça me paraît très improbable, non ?
Je suppose que tu as un code comme celui-ci :
Code:

1 2 3 4 5 6 7 8 9 file = open("texte.txt","r") liste = file.readlines() file.close() tache = liste[0] file = open("texte.txt","w") file.writelines(liste[1:]) file.close()
Il faudrait que ton second ordi, tombe pile-poil avant la réécriture ? A mon avis tu te prends le choux pour rien.

Mais sinon il y a peut-être un truc à faire avec ça (ou/et ma précédente proposition) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 import os from stat import S_IWGRP, S_IRWXG,S_IWUSR, S_IRWXU, S_IWOTH, S_IRWXO #S_IWGRP : Group has write permission #S_IRWXG : Mask for group permissions. #S_IWUSR : Owner has write permission. #S_IRWXU : Mask for file owner permissions. #S_IWOTH : Others have write permission. #S_IRWXO : Mask for permissions for others (not in group). filename = "texte.txt" os.chmod(filename, S_IRWXU)
Tu places cette ligne os.chmod(filename, S_IRWXO) avant d'ouvrir le fichier en mode lecture r... A tester ! Qu'en pensez-vous les pros ? :pastaper:

Autre proposition :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 import win32security as w32 import ntsecuritycon as con import getpass, os def lock_permission(path,user=None): sd = w32.GetFileSecurity(path, w32.DACL_SECURITY_INFORMATION) dacl = sd.GetSecurityDescriptorDacl() ordis = ["ordi1","ordi2","..."] if user == None: for ordi in ordis: user, _, _ = w32.LookupAccountName("", ordi) dacl.AddAccessDeniedAce(w32.ACL_REVISION, con.FILE_ALL_ACCESS, user) w_user, _, _ = w32.LookupAccountName("", getpass.getuser()) lock_permission(path,w_user) else: dacl.DeleteAce(0) dacl.AddAccessAllowedAce(w32.ACL_REVISION, con.GENERIC_ALL, user) sd.SetSecurityDescriptorDacl(1, dacl, 0) w32.SetFileSecurity(path, w32.DACL_SECURITY_INFORMATION, sd) def open_permission(path): sd = w32.GetFileSecurity(path, w32.DACL_SECURITY_INFORMATION) dacl = sd.GetSecurityDescriptorDacl() user, _, _ = w32.LookupAccountName("", "Tout le monde") dacl.DeleteAce(0) dacl.AddAccessAllowedAce(w32.ACL_REVISION, con.GENERIC_ALL, user) sd.SetSecurityDescriptorDacl(1, dacl, 0) w32.SetFileSecurity(path, w32.DACL_SECURITY_INFORMATION, sd) filename = "texte.txt" lock_permission(filename) file = open(filename ,"r") liste = file.readlines() file.close() tache = liste[0] file = open(filename,"w") file.writelines(liste[1:]) file.close() open_permission(filename)

Citation:

Envoyé par LeNarvalo

Vu de loin ça me paraît très improbable, non ?
Il faudrait que ton second ordi, tombe pile-poil avant la réécriture ? A mon avis tu te prends le choux pour rien.

Je suis bien d'accord avec toi... Mais je suis une pinailleuse... Une fausse note dans une jolie chanson, un bouton sur le nez le jour d'un rendez-vous, une mouche dans mon potage...

Cependant je suis un peu surprise. En faisant des tests ce matin j'ai écrit ce joli programme...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ########RENDERPYTHONSCRIPBATCH import os import poser print("-----------------") fid = "E:\\Reso\\BB.txt" if not os.path.exists(fid): RS = open(fid, "w") RS.close() p = 0 while p < 20000 : p = p + 1 if os.path.exists(fid): RS = open(fid, "rt") RS.close() if os.path.exists(fid): os.remove(fid) print("-----------------" + str(p))
Et il me retourne chaque fois un message d'erreur sur l'os.remove si j'en lance plus d'une instance (à condition que la première ne soit pas achevée avant le début de la seconde, bien sûr), depuis mon application hôte, sur un seul ou plusieurs ordi différents...
Où est l'erreur ?

As-tu ce code d'erreur ? (Un conseil poste tes messages d'erreur)
Code:

1 2 3 4 Traceback (most recent call last): File "C:\Users\******\Desktop\sybelle.py", line 6, in <module> os.remove(fid) PermissionError: [WinError 32] Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus: 'texte.txt'
Si c'est ce message alors c'est tout simplement que le fichier est encore ouvert et ne peut pas être supprimé par os.remove.

Tu peux remplacer ta boucle par un time.sleep(150) par exemple et tu devrais avoir la même erreur.

Citation:
Envoyé par LeNarvalo
As-tu ce code d'erreur ? (Un conseil poste tes messages d'erreur)
Code:

1 2 3 4 Traceback (most recent call last): File "C:\Users\******\Desktop\sybelle.py", line 6, in <module> os.remove(fid) PermissionError: [WinError 32] Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus: 'texte.txt'
Si c'est ce message alors c'est tout simplement que le fichier est encore ouvert et ne peut pas être supprimé par os.remove.

Tu peux remplacer ta boucle par un time.sleep(150) par exemple et tu devrais avoir la même erreur.
Waou ! J'ai un python à mon nom ! Ça me fait frétiller...

Nan, les codes d'erreurs que me renvoie mon appli ne sont pas très clairs (Je suis une tanche en Python, je ne sais même pas comment en lancer un sans application !)
Mais surtout je cherchais dans la mauvaise direction, persuadée que j'étais tombée sur le bug du siècle.
En fait sans le savoir je l'avais contournée en utilisant un «try» car effectivement l'erreur ne parvenait que quand tous les calculs étaient terminés (je nettoie après mon passage, je suis une fille proprette). Alors ainsi je m'éjectais du programme sans problèmes.
Bon, c'est pas vraiment résolu dans les règles de l'art mais j'ai appris des choses. Je vais les mettre en oeuvre. Mon problème sera de chercher l'impact minimal sur le temps de calcul final qui est horriblement long.

Merci à tous pour vos suggestions.

04/07/2020, 18h05
Invité

Citation:

Envoyé par SybelleDeNuit

Nan, les codes d'erreurs que me renvoie mon appli ne sont pas très clairs (Je suis une tanche en Python, je ne sais même pas comment en lancer un sans application !)

IDLE ! ;)

Bon ben si tu as résolu tes problèmes, bonne continuation alors ! :zoubi:
04/07/2020, 19h13
Sve@r

Citation:

Envoyé par SybelleDeNuit

Ben... Qui peut le plus peux le moins

Non, ce "plus" est totalement inutile. Il est totalement inutile de vouloir être le seul à pouvoir lire un fichier durant son temps de lecture si le fichier n'est pas modifié. Et s'il est modifié alors on ne l'ouvre pas en lecture.

Citation:

Envoyé par SybelleDeNuit

Il est ouvert en lecture pour récupérer le nom du job, puis en écriture pour être modifié. C'est pendant ce temps de LECTURE que je veux le rendre inaccessible afin que le job ne soit pas fait 2 fois.

Pourquoi l'ouvrir 2 fois ? Tu l'ouvres une fois en "r+" (lecture/écriture) avec un lock !!! Et donc pendant le temps de LECTURE qui se trouve être aussi le temps d'écriture personne ne peut y accéder. Méfie-toi du problème XY.
04/07/2020, 20h38
wiztricks

Citation:

Envoyé par Sve@r

Tu l'ouvres une fois en "r+" (lecture/écriture) avec un lock !!!

Par curiosité, j'ai essayé sur Windows avec 2 process qui font open(.., 'r+'), et je peux lire et écrire sans erreur. Après si on ajoute un "lock", sûr que c'est différent, mais un "lock" en réseau c'est encore autre chose

- W
05/07/2020, 08h28
Sve@r
Citation:

Envoyé par wiztricks

Par curiosité, j'ai essayé sur Windows avec 2 process qui font open(.., 'r+'), et je peux lire et écrire sans erreur.

Oui tout à fait. L'ouverture en elle-même n'est pas exclusive et c'est le dernier qui écrit qui gagne. Le lock doit être ajouté manuellement (encore que sous Windows je pensais l'OS capable de verrou vu que parfois on ne peut pas modifier un fichier ouvert par un autre truc).
Mais ce que je voulais dire de façon générale, c'est que c'est totalement absurde de mettre un lock sur de la lecture seule. D'autant plus dans l'algo originel présenté par SybelleDeNuit qui était le suivant
- j'ouvre le fichier en lecture avec un lock
- je lis ce qu'il y a
- je ferme le fichier ce qui libère le lock ce qui permet alors à d'autres processus de venir lire le fichier
- j'ouvre le fichier en écriture (trop tard, les autres ont lu ce qu'il y a dedans)
- je mets à jour le fichier
- je ferme le fichier
Si elle réfléchit 2mn (au lieu de vouloir toujours nous prouver qu'elle a raison et que c'est nous qui ne comprenons rien) elle se rendra aisément compte que même avec un lock sur la lecture cela n'empéchait pas les autres de lire le même job.