Bonjour,
Existe-il une option quelque part permettant d'activer le
verrouillage des fichiers pour remédier à ce problème ?
Bonjour,
Existe-il une option quelque part permettant d'activer le
verrouillage des fichiers pour remédier à ce problème ?
Bonjour,
Existe-il une option quelque part permettant d'activer le
verrouillage des fichiers pour remédier à ce problème ?
Bonjour,
[...]
Existe-il une option quelque part permettant d'activer le verrouillage
des fichiers pour remédier à ce problème [de partage de fi chiers en
écriture] ?
Bonjour,
[...]
Existe-il une option quelque part permettant d'activer le verrouillage
des fichiers pour remédier à ce problème [de partage de fi chiers en
écriture] ?
Bonjour,
[...]
Existe-il une option quelque part permettant d'activer le verrouillage
des fichiers pour remédier à ce problème [de partage de fi chiers en
écriture] ?
Bonjour,
J'ai un poste Linux utilisé comme serveur de terminaux (LTSP ou FreeNX).
Donc plusieurs personnes travaillent simultanément sur le même ordinateur.
Si deux personnes ouvrent le même fichier (ex : un fichier OpenOffice),
[...]
Bonjour,
J'ai un poste Linux utilisé comme serveur de terminaux (LTSP ou FreeNX).
Donc plusieurs personnes travaillent simultanément sur le même ordinateur.
Si deux personnes ouvrent le même fichier (ex : un fichier OpenOffice),
[...]
Bonjour,
J'ai un poste Linux utilisé comme serveur de terminaux (LTSP ou FreeNX).
Donc plusieurs personnes travaillent simultanément sur le même ordinateur.
Si deux personnes ouvrent le même fichier (ex : un fichier OpenOffice),
[...]
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).
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).
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).
Bonjour Sylvain,
[...]
> # mount -o remount,mand /home
> $ chmod g+s,g-x toto
>
Et comment faire pour que tous les nouveaux fichiers créés par mes
utilisateurs comporte cette marque mais sans perturber le reste du
système.
De plus, cette option de montage spéciale, ne risque t-elle pas de
perturber le reste du système en vérouillant des fichiers et em pêchant
par exemple l'installation de nouveaux paquets si des fichiers sont
vérouillés ?
[...]
> (Et si j'ai utilisé oowriter, c'est bien parce que c'est une des r ares
> applications à poser un verrou.)
>
Justement, mon problème concerne dans 95% des cas uniquement des
fichiers OOo (version 1.1.5). Donc si cela marche déjà avec OOo , ce
sera déjà très bien.
[...]
> Donc, en fait, c'est ingérable au niveau du système de fich iers.
> C'est au niveau de l'application que cela doit se faire (et ce n'est
> généralement pas le cas).
>
OK, mais si ça marche pour OOo, c'est déjà mieux que rien.
Merci beaucoup pour la réponse.
Bonjour Sylvain,
[...]
> # mount -o remount,mand /home
> $ chmod g+s,g-x toto
>
Et comment faire pour que tous les nouveaux fichiers créés par mes
utilisateurs comporte cette marque mais sans perturber le reste du
système.
De plus, cette option de montage spéciale, ne risque t-elle pas de
perturber le reste du système en vérouillant des fichiers et em pêchant
par exemple l'installation de nouveaux paquets si des fichiers sont
vérouillés ?
[...]
> (Et si j'ai utilisé oowriter, c'est bien parce que c'est une des r ares
> applications à poser un verrou.)
>
Justement, mon problème concerne dans 95% des cas uniquement des
fichiers OOo (version 1.1.5). Donc si cela marche déjà avec OOo , ce
sera déjà très bien.
[...]
> Donc, en fait, c'est ingérable au niveau du système de fich iers.
> C'est au niveau de l'application que cela doit se faire (et ce n'est
> généralement pas le cas).
>
OK, mais si ça marche pour OOo, c'est déjà mieux que rien.
Merci beaucoup pour la réponse.
Bonjour Sylvain,
[...]
> # mount -o remount,mand /home
> $ chmod g+s,g-x toto
>
Et comment faire pour que tous les nouveaux fichiers créés par mes
utilisateurs comporte cette marque mais sans perturber le reste du
système.
De plus, cette option de montage spéciale, ne risque t-elle pas de
perturber le reste du système en vérouillant des fichiers et em pêchant
par exemple l'installation de nouveaux paquets si des fichiers sont
vérouillés ?
[...]
> (Et si j'ai utilisé oowriter, c'est bien parce que c'est une des r ares
> applications à poser un verrou.)
>
Justement, mon problème concerne dans 95% des cas uniquement des
fichiers OOo (version 1.1.5). Donc si cela marche déjà avec OOo , ce
sera déjà très bien.
[...]
> Donc, en fait, c'est ingérable au niveau du système de fich iers.
> C'est au niveau de l'application que cela doit se faire (et ce n'est
> généralement pas le cas).
>
OK, mais si ça marche pour OOo, c'est déjà mieux que rien.
Merci beaucoup pour la réponse.
