Acces exclusif a un fichier

Le
xavier
Bonjour,

J'ai bien lu section sur le file locking (et les flags de sysopen) dans
perlopentut, mais ça ne résoud pas mon problème : en fait, je veux
m'assurer que je n'ouvre pas un fichier (r/o), pendant qu'un autre
processus l'a ouvert en r/w. Tous les essais que j'ai pu mener me
montrent que Perl ouvre dans tous les cas le fichier, même si je demande
une ouverture r/w, même s'il a déja été ouvert r/w par un autre process.

Murphy says : un jour j'aurai du garbage dans ce fichier.

Est-ce que gérer ce genre de situation est possible en Perl ?

Si ce n'est pas possible, un coup d'oeil dans le source de l'autre
programme me montre que comme c'est la bonne pratique, il utilise la
séquence suivante
- open r/o fichier original, close
- open r/w fichier temp
- modif data en mémoire ou directement dans temp, close temp
- rename original -> .bak, rename temp -> original

La question subsidiaire est donc plus Unix que Perl : le rename(2) est
il "suffisamment" atomique ? La question reste la même si c'est moi qui
effectue la séquence précédente dans un srcipt shell, pour l'atomicité
de mv

Merci,

--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
xavier
Le #20880411
Xavier
le rename(2) est il "suffisamment" atomique ?



PS : j'ai bien lu la spécification POSIX : "rename may or may not be
atomic, depending on the implementations". En l'occurence, c'est
FreeBSD. La seule chose garantie par POSIX que que après rename (old,
new); new existe même en cas de crash, et donc éventuellement identique
à old, avec les modifs perdues. Bon, c'est pas du tout ma préocuppation,
ça.

Et j'avoue bien humblement que si il y a 20 ans la lecture du code
source m'aurait suffi, j'ai trop oublié pour en être sûr maintenant...

--
XAv
Disponible au 01/06/2010
Publicité
Poster une réponse
Anonyme