j'ai tenté ce soir d'utiliser rsync avec l'option -E (en local, de
disque à disque) pour backuper mes données sous Tiger. Voilà un résultat
fort peu encourageants :
building file list ... rsync: writefd_unbuffered failed to write 4092
bytes: phase "send_file_entry" [sender]: Broken pipe (32)
overflow: flags=0x61 l1=121 l2=840987237
lastname=patpro/Applications/._caststream Player 2.0
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at
/SourceCache/rsync/rsync-20/rsync/util.c(126)
rsync: connection unexpectedly closed (8 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at
/SourceCache/rsync/rsync-20/rsync/io.c(359)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Maurice Diamantini
In article , patpro ~ patrick proniewski wrote:
Salut,
j'ai tenté ce soir d'utiliser rsync avec l'option -E (en local, de disque à disque) pour backuper mes données sous Tiger. Voilà un résultat fort peu encourageants :
J'ai essayé le rsync d'Apple en utilisant : /usr/bin/rsync -a -E sur un dossier de 2.1G octets d'appli diverses (dont des petits jeux pas tous neuf : avec ressources). Tout semble s'etre bien passé si ce n'est une petite différence de taille à la fin (208 octet de moins pour la copie, sur les 2.1 Go)
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
Bref l'option -E de rsync à l'air de marcher, avec la réserve des 200 octets mystérieusement disparus.
-- Maurice Diamantini
building file list ... rsync: writefd_unbuffered failed to write 4092 bytes: phase "send_file_entry" [sender]: Broken pipe (32) overflow: flags=0x61 l11 l20987237 lastname=patpro/Applications/._caststream Player 2.0 ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at /SourceCache/rsync/rsync-20/rsync/util.c(126) rsync: connection unexpectedly closed (8 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-20/rsync/io.c(359)
des idées ?
patpro
In article <patpro-B8AC99.23142806052005@news3-e.proxad.net>,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Salut,
j'ai tenté ce soir d'utiliser rsync avec l'option -E (en local, de
disque à disque) pour backuper mes données sous Tiger. Voilà un résultat
fort peu encourageants :
J'ai essayé le rsync d'Apple en utilisant :
/usr/bin/rsync -a -E
sur un dossier de 2.1G octets d'appli diverses (dont des petits jeux pas
tous neuf : avec ressources).
Tout semble s'etre bien passé si ce n'est une petite différence de
taille à la fin (208 octet de moins pour la copie, sur les 2.1 Go)
La commande
cp -Rp
sur le meme dossier rend une bonne partie des appli inutilisables.
Bref l'option -E de rsync à l'air de marcher, avec la réserve des 200
octets mystérieusement disparus.
-- Maurice Diamantini
building file list ... rsync: writefd_unbuffered failed to write 4092
bytes: phase "send_file_entry" [sender]: Broken pipe (32)
overflow: flags=0x61 l11 l20987237
lastname=patpro/Applications/._caststream Player 2.0
ERROR: buffer overflow in receive_file_entry
rsync error: error allocating core memory buffers (code 22) at
/SourceCache/rsync/rsync-20/rsync/util.c(126)
rsync: connection unexpectedly closed (8 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at
/SourceCache/rsync/rsync-20/rsync/io.c(359)
j'ai tenté ce soir d'utiliser rsync avec l'option -E (en local, de disque à disque) pour backuper mes données sous Tiger. Voilà un résultat fort peu encourageants :
J'ai essayé le rsync d'Apple en utilisant : /usr/bin/rsync -a -E sur un dossier de 2.1G octets d'appli diverses (dont des petits jeux pas tous neuf : avec ressources). Tout semble s'etre bien passé si ce n'est une petite différence de taille à la fin (208 octet de moins pour la copie, sur les 2.1 Go)
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
Bref l'option -E de rsync à l'air de marcher, avec la réserve des 200 octets mystérieusement disparus.
-- Maurice Diamantini
building file list ... rsync: writefd_unbuffered failed to write 4092 bytes: phase "send_file_entry" [sender]: Broken pipe (32) overflow: flags=0x61 l11 l20987237 lastname=patpro/Applications/._caststream Player 2.0 ERROR: buffer overflow in receive_file_entry rsync error: error allocating core memory buffers (code 22) at /SourceCache/rsync/rsync-20/rsync/util.c(126) rsync: connection unexpectedly closed (8 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-20/rsync/io.c(359)
des idées ?
patpro
laurent.pertois
Maurice Diamantini wrote:
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Maurice Diamantini <mdiam@free.fr> wrote:
La commande
cp -Rp
sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Parce que justement c'est l'une des premières que j'ai essayé et elle ne
m'avait rien détruit au niveau des ressources, tout fonctionnait comme
les originaux.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Maurice Diamantini
In article <1gw7t54.18x343qfse2pmN%, (Laurent Pertois) wrote:
Maurice Diamantini wrote:
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit... ... je ne suis plus sûr de la commande : fink était en cours de réinstallation (récup de mon install pré-tiger), et peut-être que ce n'était donc pas le "cp" d'Apple.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple) => copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger) => copie non conforme (il manque environ 5% de la taille)
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
Conclusion : Le cp d'Apple prend bien les ressources en compte. Et il faudra probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour que les nouvelles commandes prennent en compte cette fonctionnalité de Tiger (en tout cas j'espère que ce sera suffisant !).
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner également avec les ressources. En fait, les différences de tailles que j'avais entre original et copie semblent être dues à des histoires de cache du Finder.
Avec une relance du Finder, les tailles de dossiers copiés par rsync sont identiques à l'octet pret !
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un redémarrage (relance impossible) : pour une fois que je fait un update au lieu d'un clean install... !
-- Maurice Diamantini
In article <1gw7t54.18x343qfse2pmN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Maurice Diamantini <mdiam@free.fr> wrote:
La commande
cp -Rp
sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit...
... je ne suis plus sûr de la commande : fink était en cours de
réinstallation (récup de mon install pré-tiger), et peut-être que ce
n'était donc pas le "cp" d'Apple.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de
problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple)
=> copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger)
=> copie non conforme (il manque environ 5% de la taille)
Parce que justement c'est l'une des premières que j'ai essayé et elle ne
m'avait rien détruit au niveau des ressources, tout fonctionnait comme
les originaux.
Conclusion :
Le cp d'Apple prend bien les ressources en compte. Et il faudra
probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour
que les nouvelles commandes prennent en compte cette fonctionnalité de
Tiger (en tout cas j'espère que ce sera suffisant !).
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner
également avec les ressources.
En fait, les différences de tailles que j'avais entre original et copie
semblent être dues à des histoires de cache du Finder.
Avec une relance du Finder, les tailles de dossiers copiés par rsync
sont identiques à l'octet pret !
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un
redémarrage (relance impossible) : pour une fois que je fait un update
au lieu d'un clean install... !
In article <1gw7t54.18x343qfse2pmN%, (Laurent Pertois) wrote:
Maurice Diamantini wrote:
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit... ... je ne suis plus sûr de la commande : fink était en cours de réinstallation (récup de mon install pré-tiger), et peut-être que ce n'était donc pas le "cp" d'Apple.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple) => copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger) => copie non conforme (il manque environ 5% de la taille)
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
Conclusion : Le cp d'Apple prend bien les ressources en compte. Et il faudra probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour que les nouvelles commandes prennent en compte cette fonctionnalité de Tiger (en tout cas j'espère que ce sera suffisant !).
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner également avec les ressources. En fait, les différences de tailles que j'avais entre original et copie semblent être dues à des histoires de cache du Finder.
Avec une relance du Finder, les tailles de dossiers copiés par rsync sont identiques à l'octet pret !
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un redémarrage (relance impossible) : pour une fois que je fait un update au lieu d'un clean install... !
-- Maurice Diamantini
laurent.pertois
Maurice Diamantini wrote:
In article <1gw7t54.18x343qfse2pmN%, (Laurent Pertois) wrote:
Maurice Diamantini wrote:
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit...
Eheh
... je ne suis plus sûr de la commande : fink était en cours de réinstallation (récup de mon install pré-tiger), et peut-être que ce n'était donc pas le "cp" d'Apple.
Un bon whereis devrait t'aider, ou un plutôt un which.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple)
/bin/cp plutôt, mais je chipote.
=> copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
Ouf, normal, c'est ce qu'Apple a annoncé, cp (et d'autres) sait tenir compte des ressources.
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger) => copie non conforme (il manque environ 5% de la taille)
Normal, le GNU cp n'a aucune connaissance des particularités que sont les ressources.
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
Conclusion : Le cp d'Apple prend bien les ressources en compte. Et il faudra probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour que les nouvelles commandes prennent en compte cette fonctionnalité de Tiger (en tout cas j'espère que ce sera suffisant !).
Je ne suis pas certain que la recompilation soit suffisante, je pense plutôt qu'Apple a modifié les commandes pour les adapter, ils avaient déjà cpMac mais ce dernier n'était installé qu'avec les DevTools et dans /Developer/Tools, donc pas dans le $PATH par défaut.
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner également avec les ressources.
Il faut que je teste, mais si tu le dis, je te fais confiance.
En fait, les différences de tailles que j'avais entre original et copie semblent être dues à des histoires de cache du Finder.
Possible.
Avec une relance du Finder, les tailles de dossiers copiés par rsync sont identiques à l'octet pret !
Ouf.
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un redémarrage (relance impossible) : pour une fois que je fait un update au lieu d'un clean install... !
Perso, j'ai carrément tout installé, recréé un compte utilisateur et pas importé de fichiers de préfs ou de config. Je suis reparti de propre, mais surtout parce que mon utilisateur, que je traînais depuis la 10.0, était passable crade (ben, oui, quand on découvre on fait plein de tests, on casse des trucs qu'on ne répare pas forcément bien, j'ai préféré, partir propre).
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Maurice Diamantini <mdiam@free.fr> wrote:
In article <1gw7t54.18x343qfse2pmN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
Maurice Diamantini <mdiam@free.fr> wrote:
La commande
cp -Rp
sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit...
Eheh
... je ne suis plus sûr de la commande : fink était en cours de
réinstallation (récup de mon install pré-tiger), et peut-être que ce
n'était donc pas le "cp" d'Apple.
Un bon whereis devrait t'aider, ou un plutôt un which.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de
problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple)
/bin/cp plutôt, mais je chipote.
=> copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
Ouf, normal, c'est ce qu'Apple a annoncé, cp (et d'autres) sait tenir
compte des ressources.
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger)
=> copie non conforme (il manque environ 5% de la taille)
Normal, le GNU cp n'a aucune connaissance des particularités que sont
les ressources.
Parce que justement c'est l'une des premières que j'ai essayé et elle ne
m'avait rien détruit au niveau des ressources, tout fonctionnait comme
les originaux.
Conclusion :
Le cp d'Apple prend bien les ressources en compte. Et il faudra
probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour
que les nouvelles commandes prennent en compte cette fonctionnalité de
Tiger (en tout cas j'espère que ce sera suffisant !).
Je ne suis pas certain que la recompilation soit suffisante, je pense
plutôt qu'Apple a modifié les commandes pour les adapter, ils avaient
déjà cpMac mais ce dernier n'était installé qu'avec les DevTools et dans
/Developer/Tools, donc pas dans le $PATH par défaut.
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner
également avec les ressources.
Il faut que je teste, mais si tu le dis, je te fais confiance.
En fait, les différences de tailles que j'avais entre original et copie
semblent être dues à des histoires de cache du Finder.
Possible.
Avec une relance du Finder, les tailles de dossiers copiés par rsync
sont identiques à l'octet pret !
Ouf.
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un
redémarrage (relance impossible) : pour une fois que je fait un update
au lieu d'un clean install... !
Perso, j'ai carrément tout installé, recréé un compte utilisateur et pas
importé de fichiers de préfs ou de config. Je suis reparti de propre,
mais surtout parce que mon utilisateur, que je traînais depuis la 10.0,
était passable crade (ben, oui, quand on découvre on fait plein de
tests, on casse des trucs qu'on ne répare pas forcément bien, j'ai
préféré, partir propre).
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
In article <1gw7t54.18x343qfse2pmN%, (Laurent Pertois) wrote:
Maurice Diamantini wrote:
La commande cp -Rp sur le meme dossier rend une bonne partie des appli inutilisables.
La commande cp de Mac OS X 10.4 ou une autre ?
Hum, tu sèmes le doute dans mon esprit...
Eheh
... je ne suis plus sûr de la commande : fink était en cours de réinstallation (récup de mon install pré-tiger), et peut-être que ce n'était donc pas le "cp" d'Apple.
Un bon whereis devrait t'aider, ou un plutôt un which.
Voici donc un nouvel essai (par sudo pour être sûr de ne pas avoir de problèmes de droits)
/usr/bin/cp -Rp (i.e. par Apple)
/bin/cp plutôt, mais je chipote.
=> copie conforme, **à l'octet prêt ** des 2.1 Go d'appli
Ouf, normal, c'est ce qu'Apple a annoncé, cp (et d'autres) sait tenir compte des ressources.
/sw/bin/cp -Rp (i.e. par fink, compilé **avant** tiger) => copie non conforme (il manque environ 5% de la taille)
Normal, le GNU cp n'a aucune connaissance des particularités que sont les ressources.
Parce que justement c'est l'une des premières que j'ai essayé et elle ne m'avait rien détruit au niveau des ressources, tout fonctionnait comme les originaux.
Conclusion : Le cp d'Apple prend bien les ressources en compte. Et il faudra probablement recompiler les utilitaire Gnu (e.g. fileutil pour fink) pour que les nouvelles commandes prennent en compte cette fonctionnalité de Tiger (en tout cas j'espère que ce sera suffisant !).
Je ne suis pas certain que la recompilation soit suffisante, je pense plutôt qu'Apple a modifié les commandes pour les adapter, ils avaient déjà cpMac mais ce dernier n'était installé qu'avec les DevTools et dans /Developer/Tools, donc pas dans le $PATH par défaut.
En ce qui concerne la commande rsync, 'rsync -E" semble fonctionner également avec les ressources.
Il faut que je teste, mais si tu le dis, je te fais confiance.
En fait, les différences de tailles que j'avais entre original et copie semblent être dues à des histoires de cache du Finder.
Possible.
Avec une relance du Finder, les tailles de dossiers copiés par rsync sont identiques à l'octet pret !
Ouf.
Par ailleurs, le Finder a l'air un peu bugué : figeage nécessitant un redémarrage (relance impossible) : pour une fois que je fait un update au lieu d'un clean install... !
Perso, j'ai carrément tout installé, recréé un compte utilisateur et pas importé de fichiers de préfs ou de config. Je suis reparti de propre, mais surtout parce que mon utilisateur, que je traînais depuis la 10.0, était passable crade (ben, oui, quand on découvre on fait plein de tests, on casse des trucs qu'on ne répare pas forcément bien, j'ai préféré, partir propre).
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
ludovic.cynomys
Maurice Diamantini wrote:
Par ailleurs, le Finder a l'air un peu bugué
Noooooon, c'est pas vrai ??? Ils ont gardé l'ancien 10.3.2 ???
-- Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
Maurice Diamantini <mdiam@free.fr> wrote:
Par ailleurs, le Finder a l'air un peu bugué
Noooooon, c'est pas vrai ???
Ils ont gardé l'ancien 10.3.2 ???
--
Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
