j'ai plusieurs serveurs qui doivent allez mettre à jour de l'info dans un fichier sur un drive réseau.
 
Ceux-ci doivent au départ lire le fichier, ensuite modifier des valeurs, puis le réécrire. J'ouvre le fichier en lecture, place le tout dans un array, le referme. Je fais mon traitement, j'ouvre le fichier en écriture, je réécris le data puis je referme le fichier.
 
Je voudrais éviter que 2 serveurs fassent ce traitement en meme temps. Placer un lock sur le fichier avant la première ouverture (en lecture) et le retirer seulement après la 2e fermeture du fichier (écriture)
 
flock ne semble pas être en mesure de s'aider et les fichier temporaire (du genre .lck) ne sont pas vraiment jolies
 
vous voyez une autre méthode?

Sous Windows il doit y avoir moyen de verrouiller un fichier à l'aide de l'API, il y a peut-être même un module PERL qui le fait.
 
Sous Unix, je ne connais aucun autre moyen fiable que le fichier de lock.

Qu'est-ce qui ne te conviens pas dans flock() ?
 
Elmoricq, en C POSIX, fcntl() offre des locks via les opérations F_GETLK, F_SETLK et F_SETLKW.

Ce ne sont pas des locks coopératifs ?

 
parce que flock s'applique à un filehandle de fichier ouvert. Or,  moi j'ai ca:
 

Si, mais c'est suffisant dans la plupart des cas, et probablement de le cas present. Ce qu'on veut generalement c'est que les process "in the know" ne se marchent pas dessus. Apres evidemment si un utilisateur vient editer ou supprimer le fichier a la main, on n'est pas protege.

C'est ce qui me semblait. Par contre sous Windows on peut vraiment locker un fichier apparemment (à moins que ce ne soit une feinte ?).
 
Sinon oui, les rares cas où un lock coopératif ne suffit pas, c'est parce qu'il faut passer à un niveau de sécurité supérieur.

en utilisant sysopen, je peux ouvrir un fichier en read/write, ce qui ferait mon bonheur puisque j'ouvre le fichier, le locker avec flock, puis je peux tout faire mon traitement, réécrire le fichier sans qu'un autre serveur puisse l'utiliser