je me demande s'il est est sûre de faire une image d'un système MacOS X
en service, avec carbon copy cloner par exemple. N'y a t'il pas des
fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Car en fait j'ai essayé, cela fonctionne, mais j'avais des doutes. J'ai
l'impression que le clone se fait moins bien que si j'avais démarré sur
un autre système pour le faire.
Le 20/09/07 21:06, dans <46f2c2a4$0$18258$, « Sébastien B » a écrit :
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Sous unix il y a 2 type de verrouillage : le coopératif et le obligatoire. Les 2 sont très rarement utilisés.
Le coopératif est celui par défaut d'unix. Il nécessite une coopération des 2 processus (celui qui a verrouillé et celui qui veut lire). Il est donc quasiment sûr qu'un programme de sauvegarde ne va pas tester ce mode de verrouillage et donc pourra lire les fichiers ainsi verrouillés.
Le second mode, le obligatoire, est très rare. Il marche comme sur Windows. Si un processus à verrouillé un fichier, personne ne peut le lire. Je crois que Mac OS X n'implémente même pas ce type de verrouillage.
Car en fait j'ai essayé, cela fonctionne, mais j'avais des doutes. J'ai l'impression que le clone se fait moins bien que si j'avais démarré sur un autre système pour le faire.
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un fichier dont le contenu bouge au même moment où le programme de sauvegarde est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas travailler avec le système.
Dérivé de ce cas est le problème d'une application qui utilise plusieurs fichiers simultanément. Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 20/09/07 21:06, dans <46f2c2a4$0$18258$426a34cc@news.free.fr>,
« Sébastien B » <cebcb1@NOSPAMgmail.com> a écrit :
je me demande s'il est est sûre de faire une image d'un système MacOS X
en service, avec carbon copy cloner par exemple. N'y a t'il pas des
fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui
interdiraient leur lecture.
Sous unix il y a 2 type de verrouillage : le coopératif et le obligatoire.
Les 2 sont très rarement utilisés.
Le coopératif est celui par défaut d'unix. Il nécessite une coopération des
2 processus (celui qui a verrouillé et celui qui veut lire). Il est donc
quasiment sûr qu'un programme de sauvegarde ne va pas tester ce mode de
verrouillage et donc pourra lire les fichiers ainsi verrouillés.
Le second mode, le obligatoire, est très rare. Il marche comme sur Windows.
Si un processus à verrouillé un fichier, personne ne peut le lire. Je crois
que Mac OS X n'implémente même pas ce type de verrouillage.
Car en fait j'ai essayé, cela fonctionne, mais j'avais des doutes. J'ai
l'impression que le clone se fait moins bien que si j'avais démarré sur
un autre système pour le faire.
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un
fichier dont le contenu bouge au même moment où le programme de sauvegarde
est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas
travailler avec le système.
Dérivé de ce cas est le problème d'une application qui utilise plusieurs
fichiers simultanément. Par exemple il existe des bases de données où les
données et les indexes sont dans 2 fichiers séparés. Le programme de
sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents
(car la sauvegarde prend du temps), et si la base de données à évolué, il
peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela
peut rendre la base inutilisable.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 20/09/07 21:06, dans <46f2c2a4$0$18258$, « Sébastien B » a écrit :
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Sous unix il y a 2 type de verrouillage : le coopératif et le obligatoire. Les 2 sont très rarement utilisés.
Le coopératif est celui par défaut d'unix. Il nécessite une coopération des 2 processus (celui qui a verrouillé et celui qui veut lire). Il est donc quasiment sûr qu'un programme de sauvegarde ne va pas tester ce mode de verrouillage et donc pourra lire les fichiers ainsi verrouillés.
Le second mode, le obligatoire, est très rare. Il marche comme sur Windows. Si un processus à verrouillé un fichier, personne ne peut le lire. Je crois que Mac OS X n'implémente même pas ce type de verrouillage.
Car en fait j'ai essayé, cela fonctionne, mais j'avais des doutes. J'ai l'impression que le clone se fait moins bien que si j'avais démarré sur un autre système pour le faire.
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un fichier dont le contenu bouge au même moment où le programme de sauvegarde est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas travailler avec le système.
Dérivé de ce cas est le problème d'une application qui utilise plusieurs fichiers simultanément. Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Paul Gaborit
À (at) Thu, 20 Sep 2007 23:19:59 +0200, Eric Levenez écrivait (wrote):
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un fichier dont le contenu bouge au même moment où le programme de sauvegarde est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas travailler avec le système.
Murphy aidant, c'est sûr que ça arrive ! ;-)
Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
Mauvaise base, il faut en changer... car on peut très bien arriver dans une situation similaire par une simple coupure de courant. Si on perd toute la base à cause de ça, ce n'est plus de la base de données, c'est de la roulette russe... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 20 Sep 2007 23:19:59 +0200,
Eric Levenez <usenet@levenez.com> écrivait (wrote):
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un
fichier dont le contenu bouge au même moment où le programme de sauvegarde
est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas
travailler avec le système.
Murphy aidant, c'est sûr que ça arrive ! ;-)
Par exemple il existe des bases de données où les données et les
indexes sont dans 2 fichiers séparés. Le programme de sauvegarde
arrive à sauvegarder les 2 fichiers mais à 2 instants différents
(car la sauvegarde prend du temps), et si la base de données à
évolué, il peut arriver qu'un fichier soit désynchronisé par rapport
à l'autre, et cela peut rendre la base inutilisable.
Mauvaise base, il faut en changer... car on peut très bien arriver
dans une situation similaire par une simple coupure de courant. Si on
perd toute la base à cause de ça, ce n'est plus de la base de données,
c'est de la roulette russe... ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 20 Sep 2007 23:19:59 +0200, Eric Levenez écrivait (wrote):
Le problème d'une sauvegarde d'un système actif vient de la sauvegarde d'un fichier dont le contenu bouge au même moment où le programme de sauvegarde est en train de lire. Cela est rare, mais pour être sûr il vaut mieux ne pas travailler avec le système.
Murphy aidant, c'est sûr que ça arrive ! ;-)
Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
Mauvaise base, il faut en changer... car on peut très bien arriver dans une situation similaire par une simple coupure de courant. Si on perd toute la base à cause de ça, ce n'est plus de la base de données, c'est de la roulette russe... ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
unbewusst.sein
Eric Levenez wrote:
Dérivé de ce cas est le problème d'une application qui utilise plusieurs fichiers simultanément. Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
Purée !
c'est pourquoi (entre autres choses) il vaut mieux faire les synchros la nuit. -- Une Bévue
Eric Levenez <usenet@levenez.com> wrote:
Dérivé de ce cas est le problème d'une application qui utilise plusieurs
fichiers simultanément. Par exemple il existe des bases de données où les
données et les indexes sont dans 2 fichiers séparés. Le programme de
sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents
(car la sauvegarde prend du temps), et si la base de données à évolué, il
peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela
peut rendre la base inutilisable.
Purée !
c'est pourquoi (entre autres choses) il vaut mieux faire les synchros la
nuit.
--
Une Bévue
Dérivé de ce cas est le problème d'une application qui utilise plusieurs fichiers simultanément. Par exemple il existe des bases de données où les données et les indexes sont dans 2 fichiers séparés. Le programme de sauvegarde arrive à sauvegarder les 2 fichiers mais à 2 instants différents (car la sauvegarde prend du temps), et si la base de données à évolué, il peut arriver qu'un fichier soit désynchronisé par rapport à l'autre, et cela peut rendre la base inutilisable.
Purée !
c'est pourquoi (entre autres choses) il vaut mieux faire les synchros la nuit. -- Une Bévue
Gerald
Eric Levenez wrote:
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement. Dans la réalité il s'agit le plus souvent des fichiers .DS_Store ou de disques virtuels en cours d'utilisation (celui de Parallels Desktop par exemple). Il en reste alors à l'ancienne version (qui constitue déjà une solution opérationnelle) et il suffit de le refermer et de relancer la sauvegarde pour que la mise à jour se fasse. Jamais eu de problème système sur le backup. <http://www.tri-edre.fr/fr/tribackup.html> -- Gérald
Eric Levenez <usenet@levenez.com> wrote:
je me demande s'il est est sûre de faire une image d'un système MacOS X
en service, avec carbon copy cloner par exemple. N'y a t'il pas des
fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui
interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la
sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement
opérationnels. Quand il rencontre un problème de copie pour cause de
fichier en service, il le signale simplement. Dans la réalité il s'agit
le plus souvent des fichiers .DS_Store ou de disques virtuels en cours
d'utilisation (celui de Parallels Desktop par exemple). Il en reste
alors à l'ancienne version (qui constitue déjà une solution
opérationnelle) et il suffit de le refermer et de relancer la sauvegarde
pour que la mise à jour se fasse. Jamais eu de problème système sur le
backup.
<http://www.tri-edre.fr/fr/tribackup.html>
--
Gérald
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement. Dans la réalité il s'agit le plus souvent des fichiers .DS_Store ou de disques virtuels en cours d'utilisation (celui de Parallels Desktop par exemple). Il en reste alors à l'ancienne version (qui constitue déjà une solution opérationnelle) et il suffit de le refermer et de relancer la sauvegarde pour que la mise à jour se fasse. Jamais eu de problème système sur le backup. <http://www.tri-edre.fr/fr/tribackup.html> -- Gérald
Eric Levenez
Le 21/09/07 15:19, dans <1i4sq1x.q7ee6yylrpcN%, « Gerald » a écrit :
Eric Levenez wrote:
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 €) que j'utilise est prévu pour la sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 21/09/07 15:19, dans <1i4sq1x.q7ee6yylrpcN%Gerald@alussinan.org>,
« Gerald » <Gerald@alussinan.org> a écrit :
Eric Levenez <usenet@levenez.com> wrote:
je me demande s'il est est sûre de faire une image d'un système MacOS X
en service, avec carbon copy cloner par exemple. N'y a t'il pas des
fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui
interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 €) que j'utilise est prévu pour la
sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement
opérationnels. Quand il rencontre un problème de copie pour cause de
fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les
mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un
fichier est utilisé ou non. Quelqu'un sait ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 21/09/07 15:19, dans <1i4sq1x.q7ee6yylrpcN%, « Gerald » a écrit :
Eric Levenez wrote:
je me demande s'il est est sûre de faire une image d'un système MacOS X en service, avec carbon copy cloner par exemple. N'y a t'il pas des fichiers qui ne pourront pas se copier du fait qu'ils soient en service ?
Le problème pourrait venir des verrouillages sur des fichiers qui interdiraient leur lecture.
Tri-Backup 4 de Tri-Edre (69 €) que j'utilise est prévu pour la sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Gerald
Eric Levenez wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Une supposition seulement : il me semble que Tri-Backup commence par copier le fichier et compare avec l'original après la fin de la copie avant d'écraser le fichier précédent. S'il trouve une différence il n'effectue pas la copie et rapporte une erreur. Il ne s'agirait alors pas d'une détection de fichier en service mais de détection de fichier modifié depuis le début de sa sauvegarde...
-- Gérald
Eric Levenez <usenet@levenez.com> wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les
mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un
fichier est utilisé ou non. Quelqu'un sait ?
Une supposition seulement : il me semble que Tri-Backup commence par
copier le fichier et compare avec l'original après la fin de la copie
avant d'écraser le fichier précédent. S'il trouve une différence il
n'effectue pas la copie et rapporte une erreur. Il ne s'agirait alors
pas d'une détection de fichier en service mais de détection de fichier
modifié depuis le début de sa sauvegarde...
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Une supposition seulement : il me semble que Tri-Backup commence par copier le fichier et compare avec l'original après la fin de la copie avant d'écraser le fichier précédent. S'il trouve une différence il n'effectue pas la copie et rapporte une erreur. Il ne s'agirait alors pas d'une détection de fichier en service mais de détection de fichier modifié depuis le début de sa sauvegarde...
-- Gérald
gilbert.olivier
Eric Levenez wrote:
Le 21/09/07 15:19, dans <1i4sq1x.q7ee6yylrpcN%,
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la
sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Il parle de fichier en service, pas vérouillé... Cela ne t'est jamais arrivé de ne pouvoir vider la corbeille pour cause de fichier utilisé?
-- Gilbert
Eric Levenez <usenet@levenez.com> wrote:
Le 21/09/07 15:19, dans <1i4sq1x.q7ee6yylrpcN%Gerald@alussinan.org>,
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la
sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement
opérationnels. Quand il rencontre un problème de copie pour cause de
fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les
mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un
fichier est utilisé ou non. Quelqu'un sait ?
Il parle de fichier en service, pas vérouillé... Cela ne t'est jamais
arrivé de ne pouvoir vider la corbeille pour cause de fichier utilisé?
Tri-Backup 4 de Tri-Edre (69 ¤) que j'utilise est prévu pour la
sauvegarde "miroir" en tâche de fond et fournit des clônes parfaitement opérationnels. Quand il rencontre un problème de copie pour cause de fichier en service, il le signale simplement.
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Il parle de fichier en service, pas vérouillé... Cela ne t'est jamais arrivé de ne pouvoir vider la corbeille pour cause de fichier utilisé?
-- Gilbert
Anonyme
Eric Levenez wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Eric Levenez <usenet@levenez.com> wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les
mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un
fichier est utilisé ou non. Quelqu'un sait ?
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Anonyme
Paul Gaborit wrote:
Mauvaise base, il faut en changer... car on peut très bien arriver dans une situation similaire par une simple coupure de courant. Si on perd toute la base à cause de ça, ce n'est plus de la base de données, c'est de la roulette russe... ;-)
Non, la plupart des bases marchent sur ce principe, mais cela ne l'est rend pas forcément inutilisables. Par contre, en cas d'incohérence, il faut retracer l'historique des actions depuis le dernier moment "cohérent" connu et ça peut prendre du temps....
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Mauvaise base, il faut en changer... car on peut très bien arriver
dans une situation similaire par une simple coupure de courant. Si on
perd toute la base à cause de ça, ce n'est plus de la base de données,
c'est de la roulette russe... ;-)
Non, la plupart des bases marchent sur ce principe, mais cela ne l'est
rend pas forcément inutilisables. Par contre, en cas d'incohérence, il
faut retracer l'historique des actions depuis le dernier moment
"cohérent" connu et ça peut prendre du temps....
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
(MosX.net renaît sous le nom MosX.org...)
Mauvaise base, il faut en changer... car on peut très bien arriver dans une situation similaire par une simple coupure de courant. Si on perd toute la base à cause de ça, ce n'est plus de la base de données, c'est de la roulette russe... ;-)
Non, la plupart des bases marchent sur ce principe, mais cela ne l'est rend pas forcément inutilisables. Par contre, en cas d'incohérence, il faut retracer l'historique des actions depuis le dernier moment "cohérent" connu et ça peut prendre du temps....
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* (MosX.net renaît sous le nom MosX.org...)
Eric Levenez
Le 22/09/07 9:59, dans <1i4u63a.9ev49i9bpob7N%, « Jayce Piel » a écrit :
Eric Levenez wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Ce que je comprends c'est qu'il n'y a pas de mandatory locks et que c'est donc à l'application de tester volontairement si un advisory lock est présent ou non. Vu le peu d'utilité d'un deuxième type de lock, je ne vois pas l'intérêt d'un programme de backup à tester cela.
Mais pour Tri-Backup, je ne vois toujours pas comment il pourrait voir si un fichier est ouvert ou non (sauf si le programme a explicitement posé un advisory lock dessus).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 9:59, dans <1i4u63a.9ev49i9bpob7N%jayce@mosx.org>, « Jayce
Piel » <jayce@mosx.org> a écrit :
Eric Levenez <usenet@levenez.com> wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les
mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un
fichier est utilisé ou non. Quelqu'un sait ?
Ce que je comprends c'est qu'il n'y a pas de mandatory locks et que c'est
donc à l'application de tester volontairement si un advisory lock est
présent ou non. Vu le peu d'utilité d'un deuxième type de lock, je ne vois
pas l'intérêt d'un programme de backup à tester cela.
Mais pour Tri-Backup, je ne vois toujours pas comment il pourrait voir si un
fichier est ouvert ou non (sauf si le programme a explicitement posé un
advisory lock dessus).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 9:59, dans <1i4u63a.9ev49i9bpob7N%, « Jayce Piel » a écrit :
Eric Levenez wrote:
Je viens de relire une doc Apple indiquant que Mac OS X n'avait pas les mandatory locks, alors je me demande comment Tri-Backup peut voir qu'un fichier est utilisé ou non. Quelqu'un sait ?
Ce que je comprends c'est qu'il n'y a pas de mandatory locks et que c'est donc à l'application de tester volontairement si un advisory lock est présent ou non. Vu le peu d'utilité d'un deuxième type de lock, je ne vois pas l'intérêt d'un programme de backup à tester cela.
Mais pour Tri-Backup, je ne vois toujours pas comment il pourrait voir si un fichier est ouvert ou non (sauf si le programme a explicitement posé un advisory lock dessus).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
