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>
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>
Poser une question
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