Je documente cette erreur avec Mac OS X, parce que j’ai perdu une bonne heure à trouver la solution et que, grâce à Google, cela évitera à d’autres de s’énerver comme moi. (Oui, je suis un garçon gentil.)
Je rapatrie une sauvegarde de mon serveur sous la forme d’un .tar.gz.
Dans le Finder, je double clique (ce qui lance par défaut Archive Utility - BOMArchiveHelper) et j’obtiens l’erreur :
“Erreur 1 - Opération non permise” (“Error 1 - Operation not permitted”).
Surpris, j’essaie la décompression via l’utilitaire The Unarchiver, et j’obtiens :
“Écriture dans le répertoire de destination impossible.”
Avec StuffitExpander, l’erreur est :
“An error has occured while expanding the file xxx.tar (Unspecified Stuffit Engine internal Error) Error #17999”.
Commençant à m’inquiéter de l’intégrité de mes sauvegardes serveur, je re-download, et tout pareil. Je re-download avec un autre logiciel SFTP, et encore pareil. Je décompresse directement sur le serveur, aucun problème.
J’essaye via le Terminal avec tar xvfz nom-archive.tar.gz et j’obtiens ces erreurs :
x ./: Attempt to write to an empty file
tar: Error exit delayed from previous errors.
Ce qui me permet de trouver enfin la seule page sur le Web qui donne la bonne piste.
Il s’agirait donc d’un bogue du tar de BSD/Darwin.
La stratégie de contournement est donc d’utiliser le gnutar à la place de tar : “gnutar -xvzf”.
Et ça marche !
Une équipe de chercheurs en économie comportementale ont publié une enquête expliquant comment les chances de survie sur le Titanic étaient beaucoup plus importantes pour les riches que pour les pauvres. Mais ce ne fut pas le cas pour le Lusitania (qui comportait pourtant environ le même nombre de passagers, de différentes classes sociales, et répartis en fonction sur le bateau).
Cela est dû notamment au fait que le Lusitania ayant coulé très vite, les normes sociales se sont immédiatement dissoutes et n’ont pas eu le temps de réapparaître. Pour le Titanic en revanche, qui a mis plusieurs heures à couler, les normes ont eu le temps de réapparaître. Les calculs des chercheurs déterminent que lorsqu’une catastrophe survient, il y a d’abord une réaction instinctive et biologique de panique. Ce n’est qu’au bout d’un laps de temps compris entre 18 minutes et 2 heures que les normes sociales refont surface.
Time, Jeffrey Kluger: “Titanic vs. Lusitania: How People Behave in a Disaster”.
Les “normes sociales refont surface au bout d’un laps de temps…” Comme disait Archimerdre, tout corps social plongé dans l’eau… (Je croyais que vous arrêtiez de bloguer, mais tant mieux si j’ai mal compris)
Seule la mort pourrait m’arrêter…
“Seule la mort pourrait m’arrêter…” Ça me rappelle….”je crois à la force de l’Esprit… je ne vous abandonnerai pas”. Bon, je dégage.
Moralité: Quand on est en bas de l’échelle sociale on a plus de chance de survie si le bateau coule en moins de 20 min ?
Exactement.
Oubéh, désolé, je offtopique, mais Nina, c’est vraiment de l’amateurisme.
(Sinon, Laurent, nous sommes deux à t’avoir posé une question, tu répondais à qui ?)
Aux deux :-)
@xave : awa c’est du lourd ! Nina c’est effectivement du pipi de chat en comparaison. J’adore ça : « silent obscene verbal abuse “direct to skull” ». En fait si je n’entends pas les voix que j’ai dans la tête, c’est parce qu’elles sont silencieuses !
Ceci dit, Nina, c’est un superbe sujet d’un article de blog.
@Off Topic : si les maladies mentales les plus banales font de superbes sujets de blog, on n’a pas fini.
@padawan: le même sujet fait de superbes films et on n’a pas fini :)
Mais!?!?! Quelle est cette histoire?
ah les charmes de la Normandie.
Faisons des bateaux rien que pour les vieux, les moches, les cons et le pauvres (j’en serais), foutons-les à la flotte et hop ! On les torpille. Qui s’en sortira (ou pas) ?
“embruns”, journal de bord | fins produits hypertextuels depuis 1996 | valid. | © 2010 laurent gloaguen.
1. Olivier le 3 mars 2010
Il faudrait prévenir Laurent qu’un geek vient de hacker son blog.
2. Nicolas le 3 mars 2010
Oui mais non, RTFM à la fin.
z ça ne sert qu’en mode création et pas en extraction, donc :
tar -cvz -f archive.tar.gz monrepertoireàtarer
Et pour extraire :
tar -xvf nom-archive.tar.gz
Il reconnait tout seul que c’est gzippé.
Il y a peut-être un problème avec ArchiveUtility mais je ne le reproduis pas. T’es sous Leopard ? Et rappelle-toi que tu trouves des messages d’erreur beaucoup plus détaillés dans la Console (dans Utilitaires|Utilities)
3. Laurent Gloaguen le 3 mars 2010
Je suis sous Snow Leopard.
4. Laurent Gloaguen le 3 mars 2010
Et system.log me montre les mêmes erreurs pour ArchiveUtility qu’avec tar dans le terminal.
“27/02/10 10:54:06 [0x0-0x3e03e].com.apple.archiveutility[419] ./: Attempt to write to an empty file”
5. Nicolas le 3 mars 2010
Et sur ton serveur, c’est quelle version de tar ? Tu connais la commande qui est lancée pour créer l’archive ?
J’imagine que t’as pas de problème avec des archives que tu crées sur ton mac.
6. Laurent Gloaguen le 3 mars 2010
Mon serveur est sous Debian.
tar —version : tar (GNU tar) 1.20
7. Laurent Gloaguen le 3 mars 2010
Et j’ai pas le problème avec des .tar créés en local.
8. padawan le 3 mars 2010
Bizarre, je n’ai pas de problème pour récupérer sous Mac OS X des tar faits sous Debian. C’est surtout le tar de Solaris qui me posait problème.
9. palpatine le 5 mars 2010
Je rencontre pour ma part un problème systméatique entre une (très grosse) archive tar.gz sous OpenBSD et une visualisation (la décompression est correcte) sous Linux (donc gnutar) : le dossier racine réapparaît en sous-dossier, et des sous-dossiers peuvent réapparaître en racine… Je ne sais pas comment ils ont fait leur compte. Le pire, c’est ar (bah oui, ça sert, et pas qu’à faire des bibliothèques statiques) : incompatibilité entre BSD et GNU…
10. Laurent Gloaguen le 5 mars 2010
Je me sens moins seul. Chacun sa merde :-)