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>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
xavier
Xavier wrote:
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 <http://www.xavierhumbert.net/perso/CV2.html>
Xavier <xavier@groumpf.org> wrote:
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
<http://www.xavierhumbert.net/perso/CV2.html>
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 <http://www.xavierhumbert.net/perso/CV2.html>
