Le 29 juin 08 à 16:49, Patrick Proniewski a écrit :
> On 29 juin 2008, at 15:05, Daniel Varlet wrote:
>
>> ...
>> set fx to quoted form of (get POSIX path of f)
>> (* directory only *)
>> set cmd to "2>&1 lsof +c 0 +D " & fx & " || true" (* avoid
>> undesirable
>> status 1 *)
>> set r to do shell script cmd
>> ...
>>
>> On pourrait ainsi tester si r != "".
>> Donc si r n'est pas "":
>> - Soit il y a une "vraie" erreur. Vient de la redirection de stderr.
>> (Mieux vaudrait vérifier avant que f est un dossier valide).
>> - Soit il existe un ou plusieurs fichiers ouverts dans le dossier.
>
>
> En réalité, l'inconvénient de nombreuses applications "utilisateur"
> de Mac OS X tient en ceci qu'elles ne maintiennent pas les fichiers
> ouverts au sens Unix, ce qui rend l'utilisation de lsof caduque.
>
> patpro
>
lsof n'est certainement pas adapté au désastre annoncé... Je n'y avais
pas prêté attention.
Je suppose que ces appli lisent/écrivent puis referment aussitôt les
fichiers. Mais peu importe.
Le problème comme tu l'as souligné, n'est plus une simple question
d'accès à un fichier (ni a un hypothétique et improbable bug de
iMachin qui laisserait modifier un fichier pendant qu'il est
"vraiment" ouvert), mais une politique générale de modification d'un
fichier par plusieurs utilisateurs potentiels. Il me semble alors que
c'est *beaucoup* plus complexe et spécifique.
Subversion et Cie font ça d'une certaine manière, entre autre...
Certainement plein d'autres pistes que des admins chevronnés ne
manqueront pas de révéler.
--
Daniel
_______________________________________________
archives :
http://listes.patpro.net/list/sshfr.fr.html
http://listes.patpro.net/mailman/listinfo/script_shell_fr
