Re: Verrouillage de fichiers sous Linux

[Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net>]

Mardi 19 septembre 2006, 11:45:19 CEST, Tony GALMICHE a écrit :
> 
> Bonjour,

'soir,
 
>[...]
> Existe-il une option quelque part permettant d'activer le verrouillage 
> des fichiers pour remédier à ce problème [de partage de fichiers en
> écriture] ?

Réponse courte : Oui, mais en fait non.

Réponse longue :

  Il existe des mécanismes Unix/POSIX pour verrouiller des fichiers ou
des morceaux de fichiers (c'est sans doute ceux que Samba utilise), mais :
— rares sont les applications qui s'en servent ;
— par défaut, ces verrous ne sont pas obligatoires : les processus
  doivent coopérer.

  Pour rendre ces verrous obligatoires, mount a l'option « mand ».
(Samba étant la seule application à servir les fichiers partagés, elle
 honore ses propres verrous.)

  Ensuite, pour les fichiers pour lesquels on veut que les verrous soient
obligatoires doivent être marqués par un droit spécial, qui, normalement,
ne veut rien dire : g+s,g-x (s ne veut rien dire sans x) :

# mount -o remount,mand /home
$ chmod g+s,g-x toto

et si un processus verrouille toto, le verrou sera obligatoire.

Chouette ! ... ben non : cela ne fonctionne que _si_ un processus pose un
verrou ! Et de nombreuses applications n'en posent pas, ou bien,
simplement, mettent le fichier en mémoire et le ferment aussitôt.

Scénario de contournement d'un verrou :
 1. A ouvre un fichier, met un verrou partagé (= on peut lire mais pas
    écrire) ;
 2. B ouvre le même fichier, en lecture seule à cause du/grâce au verrou,
    le met en mémoire, puis le ferme ;
 –. A et B manipulent le _document_ (pas le fichier, en tout cas pas B) ;
 3. A ferme le fichier, lâche le verrou ;
 4. B écrase le fichier à la sauvegarde.

  Si les étapes 3 et 4 sont inversées :
— soit B est bloqué tant que A n'a pas lâché le verrou ;
   (Je viens de tester avec oowriter et kword : oowriter est A, kword est
    B. Quand kword essaie de sauver : il est bloqué/figé jusqu'à ce que
    oowriter ferme le fichier. Ça peut surprendre un utilisateur...)
— soit B est malin : il vérifie la présence d'un verrou et prévient.

(Et si j'ai utilisé oowriter, c'est bien parce que c'est une des rares
 applications à poser un verrou.)

Même les verrous de Samba n'empêchent pas ce scénario :
 1. A ouvre, lit, met en mémoire, ferme ;
 2. B ouvre, lit, met en mémoire, ferme ;
 3. A écrase ;
 4. B écrase.

  Pour les utilisateurs, le _document_ est resté ouvert. Pour le système
de fichiers, le _fichier_ correspondant a été ouvert/fermé par un seul
processus à la fois.

  Donc, en fait, c'est ingérable au niveau du système de fichiers. C'est
au niveau de l'application que cela doit se faire (et ce n'est
généralement pas le cas).

-- 
 Sylvain Sauvage