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 22/09/07 9:46, dans <1i4u5pb.1jwuy4s146t22kN%, « Gilbert OLIVIER » a écrit :
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é?
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Tri-Edge ne veut pas effacer un fichier mais il veut simplement voir si il est ouvert. Il y a des API pour cela (voir la commande lsof par exemple), mais c'est toujours une fonction retardée : entre le moment où l'on test si le fichier est ouvert ou non et le moment où on commence et où on finit de l'utiliser, il peut se passer 15 plombes. De plus si tri-Edge ne copiait pas les fichiers ouverts, la copie ne contiendrait pas le Finder, pas Tri-Edge lui-même et pas toute une partie du système qui est utilisée en permanence par 36 processus : la copie serait inutilisable et bien sûr pas bootable.
Pour l'effacement de la poubelle, le Finder fait un appel système "delete" sur le fichier et n'utilise ainsi pas l'appel système POSIX "unlink" (qui lui, bien sûr, marche sur les fichiers ouverts). Je suppose que ce "delete" retourne une erreur si le fichier est utilisé (contrairement au unlink POSIX), mais je n'ai trouvé aucune doc sur ce "delete" chez Apple... Étrange cet appel système.
-- É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:46, dans <1i4u5pb.1jwuy4s146t22kN%gilbert.olivier@orange.fr>,
« Gilbert OLIVIER » <gilbert.olivier@orange.fr> a écrit :
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é?
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais
arrivé. J'aimerais bien comprendre comment le système voit si un fichier est
ouvert ou non...
Tri-Edge ne veut pas effacer un fichier mais il veut simplement voir si il
est ouvert. Il y a des API pour cela (voir la commande lsof par exemple),
mais c'est toujours une fonction retardée : entre le moment où l'on test si
le fichier est ouvert ou non et le moment où on commence et où on finit de
l'utiliser, il peut se passer 15 plombes. De plus si tri-Edge ne copiait pas
les fichiers ouverts, la copie ne contiendrait pas le Finder, pas Tri-Edge
lui-même et pas toute une partie du système qui est utilisée en permanence
par 36 processus : la copie serait inutilisable et bien sûr pas bootable.
Pour l'effacement de la poubelle, le Finder fait un appel système "delete"
sur le fichier et n'utilise ainsi pas l'appel système POSIX "unlink" (qui
lui, bien sûr, marche sur les fichiers ouverts). Je suppose que ce "delete"
retourne une erreur si le fichier est utilisé (contrairement au unlink
POSIX), mais je n'ai trouvé aucune doc sur ce "delete" chez Apple... Étrange
cet appel système.
--
É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:46, dans <1i4u5pb.1jwuy4s146t22kN%, « Gilbert OLIVIER » a écrit :
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é?
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Tri-Edge ne veut pas effacer un fichier mais il veut simplement voir si il est ouvert. Il y a des API pour cela (voir la commande lsof par exemple), mais c'est toujours une fonction retardée : entre le moment où l'on test si le fichier est ouvert ou non et le moment où on commence et où on finit de l'utiliser, il peut se passer 15 plombes. De plus si tri-Edge ne copiait pas les fichiers ouverts, la copie ne contiendrait pas le Finder, pas Tri-Edge lui-même et pas toute une partie du système qui est utilisée en permanence par 36 processus : la copie serait inutilisable et bien sûr pas bootable.
Pour l'effacement de la poubelle, le Finder fait un appel système "delete" sur le fichier et n'utilise ainsi pas l'appel système POSIX "unlink" (qui lui, bien sûr, marche sur les fichiers ouverts). Je suppose que ce "delete" retourne une erreur si le fichier est utilisé (contrairement au unlink POSIX), mais je n'ai trouvé aucune doc sur ce "delete" chez Apple... Étrange cet appel système.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 22/09/07 8:16, dans <1i4u0fb.muuon11xy536aN%, « Gerald » 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 ?
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...
Ça, oui, c'est possible, et très simplement. D'ailleurs la commande unix tar, par exemple, marche sur ce principe :
Avant la sauvegarde d'un fichier, son "stat" est sauvegardé. C'est une structure qui contient entre autre la taille du fichier et la date de sa dernière modification. Juste après la sauvegarde du fichier, tar relit le "stat" du fichier et compare. Si il y a une différence, c'est que le fichier a changé et donc un warning est retourné (il est inutile de relire le fichier).
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent suffisant) des incohérences sur les fichiers sauvegardés.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 8:16, dans <1i4u0fb.muuon11xy536aN%Gerald@alussinan.org>,
« Gerald » <Gerald@alussinan.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 ?
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...
Ça, oui, c'est possible, et très simplement. D'ailleurs la commande unix
tar, par exemple, marche sur ce principe :
Avant la sauvegarde d'un fichier, son "stat" est sauvegardé. C'est une
structure qui contient entre autre la taille du fichier et la date de sa
dernière modification. Juste après la sauvegarde du fichier, tar relit le
"stat" du fichier et compare. Si il y a une différence, c'est que le fichier
a changé et donc un warning est retourné (il est inutile de relire le
fichier).
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit
pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent
suffisant) des incohérences sur les fichiers sauvegardés.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 8:16, dans <1i4u0fb.muuon11xy536aN%, « Gerald » 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 ?
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...
Ça, oui, c'est possible, et très simplement. D'ailleurs la commande unix tar, par exemple, marche sur ce principe :
Avant la sauvegarde d'un fichier, son "stat" est sauvegardé. C'est une structure qui contient entre autre la taille du fichier et la date de sa dernière modification. Juste après la sauvegarde du fichier, tar relit le "stat" du fichier et compare. Si il y a une différence, c'est que le fichier a changé et donc un warning est retourné (il est inutile de relire le fichier).
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent suffisant) des incohérences sur les fichiers sauvegardés.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <C31AABB6.B5329%, Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas forcément le système qui voit cela, ça peut aussi être en dessus et ne concerner que les fichiers ouverts via Carbon, Cococa, ...
Patrick -- Patrick Stadelmann
In article <C31AABB6.B5329%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais
arrivé. J'aimerais bien comprendre comment le système voit si un fichier est
ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas
forcément le système qui voit cela, ça peut aussi être en dessus et ne
concerner que les fichiers ouverts via Carbon, Cococa, ...
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas forcément le système qui voit cela, ça peut aussi être en dessus et ne concerner que les fichiers ouverts via Carbon, Cococa, ...
Patrick -- Patrick Stadelmann
Eric Levenez
Le 22/09/07 11:38, dans , « Patrick Stadelmann » a écrit :
In article <C31AABB6.B5329%, Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas forcément le système qui voit cela, ça peut aussi être en dessus et ne concerner que les fichiers ouverts via Carbon, Cococa, ...
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 11:38, dans
<Patrick.Stadelmann-E3D82C.11385822092007@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <C31AABB6.B5329%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais
arrivé. J'aimerais bien comprendre comment le système voit si un fichier est
ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas
forcément le système qui voit cela, ça peut aussi être en dessus et ne
concerner que les fichiers ouverts via Carbon, Cococa, ...
Je viens de tester, et cela marche pour tout fichier (même sous shell), et
cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je
n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 11:38, dans , « Patrick Stadelmann » a écrit :
In article <C31AABB6.B5329%, Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Essaye avec un document Word ouvert par exemple. Mais c'est pas forcément le système qui voit cela, ça peut aussi être en dessus et ne concerner que les fichiers ouverts via Carbon, Cococa, ...
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
gilbert.olivier
Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets ce fichier dans la corbeille, si tu tentes de la vider, tu as un message comme quoi ce fichier est utilisé.
-- Gilbert
Eric Levenez <usenet@levenez.com> wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais
arrivé. J'aimerais bien comprendre comment le système voit si un fichier est
ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu
ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets
ce fichier dans la corbeille, si tu tentes de la vider, tu as un message
comme quoi ce fichier est utilisé.
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets ce fichier dans la corbeille, si tu tentes de la vider, tu as un message comme quoi ce fichier est utilisé.
-- Gilbert
Eric Levenez
Le 22/09/07 13:07, dans <1i4uewk.vngzyd115ebzfN%, « Gilbert OLIVIER » a écrit :
Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets ce fichier dans la corbeille, si tu tentes de la vider, tu as un message comme quoi ce fichier est utilisé.
J'ai expliqué dans mon précédent mail que j'avais testé cela et qu'effectivement le Finder ne peut effacer un fichier ouvert. Cela semble dû à l'utilisation d'une API non documentée et non POSIX, "delete". Mais il n'empêche que n'importe quelle programme peut effacer tout fichier même en cours d'utilisation (si il a les droits d'accès bien sûr). C'est le Finder qui se limite volontairement.
Mais comme je l'ai dit aussi dans mes emails précédent, que ce fait le Finder sur l'effacement de fichiers n'a rien à voir avec ce que fait Tri-Backup pendant sa sauvegarde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 13:07, dans <1i4uewk.vngzyd115ebzfN%gilbert.olivier@orange.fr>,
« Gilbert OLIVIER » <gilbert.olivier@orange.fr> a écrit :
Eric Levenez <usenet@levenez.com> wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais
arrivé. J'aimerais bien comprendre comment le système voit si un fichier est
ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu
ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets
ce fichier dans la corbeille, si tu tentes de la vider, tu as un message
comme quoi ce fichier est utilisé.
J'ai expliqué dans mon précédent mail que j'avais testé cela et
qu'effectivement le Finder ne peut effacer un fichier ouvert. Cela semble dû
à l'utilisation d'une API non documentée et non POSIX, "delete". Mais il
n'empêche que n'importe quelle programme peut effacer tout fichier même en
cours d'utilisation (si il a les droits d'accès bien sûr). C'est le Finder
qui se limite volontairement.
Mais comme je l'ai dit aussi dans mes emails précédent, que ce fait le
Finder sur l'effacement de fichiers n'a rien à voir avec ce que fait
Tri-Backup pendant sa sauvegarde.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 13:07, dans <1i4uewk.vngzyd115ebzfN%, « Gilbert OLIVIER » a écrit :
Eric Levenez wrote:
Pour démonter un disque oui, pour vider la poubelle cela ne m'est jamais arrivé. J'aimerais bien comprendre comment le système voit si un fichier est ouvert ou non...
Ce n'est pas moi qui vais te l'expliquer :-), mais par exemple, tu ouvres un fichier (je viens d'essayer avec un jpg) avec Aperçu, tu mets ce fichier dans la corbeille, si tu tentes de la vider, tu as un message comme quoi ce fichier est utilisé.
J'ai expliqué dans mon précédent mail que j'avais testé cela et qu'effectivement le Finder ne peut effacer un fichier ouvert. Cela semble dû à l'utilisation d'une API non documentée et non POSIX, "delete". Mais il n'empêche que n'importe quelle programme peut effacer tout fichier même en cours d'utilisation (si il a les droits d'accès bien sûr). C'est le Finder qui se limite volontairement.
Mais comme je l'ai dit aussi dans mes emails précédent, que ce fait le Finder sur l'effacement de fichiers n'a rien à voir avec ce que fait Tri-Backup pendant sa sauvegarde.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Gerald
Eric Levenez wrote:
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent suffisant) des incohérences sur les fichiers sauvegardés.
Je crois qu'en fait ça semble plus subtil que ça mais *ça marche* et c'est ce qui m'importe : mon disque de sauvegarde bootable n'a jamais refusé de booter NI DE TRAVAILLER DESSUS à l'exception notable de certains softs, peu nombreux, dotés de protections de merde : citons au hasard ProLexis ou ContentBarrier...
En cas de besoin, ne pas hésiter à les contacter : les gens de Tri-Edre France sont non seulement français mais surtout à la fois charmants ET compétents, ce sont en gros des cousins des concepteurs du logiciel ou quasi qui répondent aux questions pointues. J'en suis vraiment très content.
<http://www.tri-edre.fr/fr/index.html>
-- Gérald
Eric Levenez <usenet@levenez.com> wrote:
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit
pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent
suffisant) des incohérences sur les fichiers sauvegardés.
Je crois qu'en fait ça semble plus subtil que ça mais *ça marche* et
c'est ce qui m'importe : mon disque de sauvegarde bootable n'a jamais
refusé de booter NI DE TRAVAILLER DESSUS à l'exception notable de
certains softs, peu nombreux, dotés de protections de merde : citons au
hasard ProLexis ou ContentBarrier...
En cas de besoin, ne pas hésiter à les contacter : les gens de Tri-Edre
France sont non seulement français mais surtout à la fois charmants ET
compétents, ce sont en gros des cousins des concepteurs du logiciel ou
quasi qui répondent aux questions pointues. J'en suis vraiment très
content.
Tri-Backup peut utiliser ce principe très simple en effet. Cela n'interdit pas la sauvegarde des fichiers ouverts, et indique juste (mais c'est souvent suffisant) des incohérences sur les fichiers sauvegardés.
Je crois qu'en fait ça semble plus subtil que ça mais *ça marche* et c'est ce qui m'importe : mon disque de sauvegarde bootable n'a jamais refusé de booter NI DE TRAVAILLER DESSUS à l'exception notable de certains softs, peu nombreux, dotés de protections de merde : citons au hasard ProLexis ou ContentBarrier...
En cas de besoin, ne pas hésiter à les contacter : les gens de Tri-Edre France sont non seulement français mais surtout à la fois charmants ET compétents, ce sont en gros des cousins des concepteurs du logiciel ou quasi qui répondent aux questions pointues. J'en suis vraiment très content.
<http://www.tri-edre.fr/fr/index.html>
-- Gérald
Patrick Stadelmann
In article <C31AB07A.B533B%, Eric Levenez wrote:
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de détruire un fichier qui est ouvert.
Patrick -- Patrick Stadelmann
In article <C31AB07A.B533B%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Je viens de tester, et cela marche pour tout fichier (même sous shell), et
cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je
n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui
a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de
détruire un fichier qui est ouvert.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de détruire un fichier qui est ouvert.
Patrick -- Patrick Stadelmann
Eric Levenez
Le 22/09/07 20:30, dans , « Erwan David » a écrit :
Eric Levenez écrivait :
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).
lsof nous donne bien les fichiers ouverts...
On peut effectivement connaître les fichiers ouverts à un instant donné, mais pas en temps réel. Je pense que lsof regarde directement en mémoire dans xnu pour voir la liste des processus et les fichiers ouverts. C'est une sorte de dump mémoire, et cela consomme beaucoup de ressources. À ma connaissance ce n'est pas un simple appel système. Mais Apple a pu en ajouter un, non POSIX, pour cela, de la même manière que l'appel système delete semble être un ajout par rapport à unlink/remove de la norme. Ça, j'aimerais bien le savoir.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 20:30, dans <m2ir621rjc.fsf@ratagaz.depot.rail.eu.org>, « Erwan
David » <erwan@rail.eu.org> a écrit :
Eric Levenez <usenet@levenez.com> écrivait :
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).
lsof nous donne bien les fichiers ouverts...
On peut effectivement connaître les fichiers ouverts à un instant donné,
mais pas en temps réel. Je pense que lsof regarde directement en mémoire
dans xnu pour voir la liste des processus et les fichiers ouverts. C'est une
sorte de dump mémoire, et cela consomme beaucoup de ressources. À ma
connaissance ce n'est pas un simple appel système. Mais Apple a pu en
ajouter un, non POSIX, pour cela, de la même manière que l'appel système
delete semble être un ajout par rapport à unlink/remove de la norme. Ça,
j'aimerais bien le savoir.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 20:30, dans , « Erwan David » a écrit :
Eric Levenez écrivait :
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).
lsof nous donne bien les fichiers ouverts...
On peut effectivement connaître les fichiers ouverts à un instant donné, mais pas en temps réel. Je pense que lsof regarde directement en mémoire dans xnu pour voir la liste des processus et les fichiers ouverts. C'est une sorte de dump mémoire, et cela consomme beaucoup de ressources. À ma connaissance ce n'est pas un simple appel système. Mais Apple a pu en ajouter un, non POSIX, pour cela, de la même manière que l'appel système delete semble être un ajout par rapport à unlink/remove de la norme. Ça, j'aimerais bien le savoir.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 22/09/07 21:39, dans , « Patrick Stadelmann » a écrit :
In article <C31AB07A.B533B%, Eric Levenez wrote:
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de détruire un fichier qui est ouvert.
Ça c'est intéressant et cela correspond à ce que j'ai trouvé sur ma machine :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/07 21:39, dans
<Patrick.Stadelmann-610D34.21391722092007@individual.net>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <C31AB07A.B533B%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Je viens de tester, et cela marche pour tout fichier (même sous shell), et
cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je
n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui
a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de
détruire un fichier qui est ouvert.
Ça c'est intéressant et cela correspond à ce que j'ai trouvé sur ma machine
:-)
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/07 21:39, dans , « Patrick Stadelmann » a écrit :
In article <C31AB07A.B533B%, Eric Levenez wrote:
Je viens de tester, et cela marche pour tout fichier (même sous shell), et cela est dû à l'appel système "delete" (et pas "unlink/remove") dont je n'arrive pas à trouver la doc. C'est donc le noyau qui voit cela.
D'après "Mac OS X Internals", "delete" est une variante de "unlink" qui a un comportement "Carbon" au lieu de "POSIX", i.e. qui refuse de détruire un fichier qui est ouvert.
Ça c'est intéressant et cela correspond à ce que j'ai trouvé sur ma machine :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
