[Résolu] Fichier ODT corrompu > récupération possible ?

[kratosangel]

Bonjour,

Ma compagne a eu un problème avec 2 fichiers ODT qui sont devenus soudainement corrompus (travail directement sur la clé USB ...).
Je voulais savoir s'il y avait une quelconque façon de récupérer ?
L'outil de test du forum m'a dit que le fichier était zippable/dézippable et qu'il y avait donc de l'espoir.
J'ai donc tenté de zippé le fichier puis de supprimer 'styles.xml' de l'archive mais sans résultat.
J'ai ensuite tenté de tout dézipper mais cela ne fonctionne pas car le 'content.xml' refuse de s'extraire car "corrompu" (sans blague ?).
Via un dézippeur en ligne j'ai réussi à télécharger le content.xml mais il arrivait avec 0 octet de taille et même le réparateur XML n'a rien pu faire.
Pourtant, le fichier de base a une taille supérieure.

Elle travaillait plutôt sous Libre Office mais je n'ai pas trouvé de suite de ce côté, j'espère pouvoir avoir de l'aide ici donc.
Si jamais c'était irrécupérable, est-il possible de récupérer d'anciennes versions depuis son PC/clé USB potentiellement ?

Merci d'avance pour elle.

[Jean-Louis Cadeillan]

Bonjour et bienvenue,
Désolé, je n'ai pas trouvé de réparation valable. Pour préciser les choses, j'ai utilisée ZipRepar et Zip2Fix pour réparer les zip, mais pour séances 6 et 7.odt, le content.xml réparé par l'utilitaire de réparation XML de Scrat ne contient que des styles (même avant réparation, d'ailleurs), pas de texte. Pour seduta 1.odt, la méthode de compression du content.xml est non valide et donc rien à extraire.

Si jamais c'était irrécupérable, est-il possible de récupérer d'anciennes versions depuis son PC/clé USB potentiellement ?

Voir le tuto de Papayes ici.
Pour éviter que cela ne se reproduise, quelques conseils...
Cordialement,
Jean-Louis

[kratosangel]

Bonjour,

Merci beaucoup pour cette réponse, même si ce sont malheureusement de mauvaises nouvelles car pas de version précédentes trouvées
Serait-il possible de tester avec cet autre fichier ?
Ce fichier fonctionnait très bien et d'un coup, il a décidé d'être corrompu également.
C'est un truc de fou de comment c'est absolument pas fiable ces documents ? Elle a eu en quelques minutes seulement beaucoup plus de documents corrompus, en utilisant cette fois ci Word 2016 (format ODT).
Est-ce un problème sur l'ordinateur qui pourrait expliquer ça ou est-ce que c'est Word à éviter comme la peste ?
Il y a également des documents qui allaient très bien, jamais édités depuis des mois et, tout à coup, deviennent corrompus ??? O_o
En effet, sur un problème pareil, même des sauvegardes incrémentales ne seraient d'aucun secours.

Edit : fichier trop lourd --> https://www.cjoint.com/c/IHwpGwK7vpX

[Jean-Louis Cadeillan]

Serait-il possible de tester avec cet autre fichier ?

Quel autre fichier ?

utilisant cette fois ci Word 2016 (format ODT)

Voir ce tuto.
Cordialement,
Jean-Louis

[kratosangel]

Oups, au temps pour moi, j'avais raté le message d'erreur de taille trop important, j'ai édité le post dessus pour l'ajouter.

Merci beaucoup pour ce tuto intéressant, plein de choses bonnes à savoir que j'ignorais moi-même : j'ai eu de la chance jusque là, aucune corruption, mais je vais appliquer ces conseils aussi pour éviter des futurs problèmes.
Dommage que la sauvegarde incrémentale ne soit pas cochée par défaut.

Si je comprends bien, manipuler du ODT avec Word, c'est le mal (et donc Microsoft est particulièrement sadique en proposant d'enregistrer en ODT plutôt que doc par défaut ?)
Egalement les formats .doc sont bien plus susceptibles d'être corrompus et irrécupérables ?
La conclusion serait donc : pour vivre "en sécurité", mieux vaut rester le plus loin possible de Word et privilégier Libre Office ?

[Jean-Louis Cadeillan]

Dommage que la sauvegarde incrémentale ne soit pas cochée par défaut.

Ne pas confondre Toujours créer une copie de sauvegarde à cocher dans les options, avec la sauvegarde avec incrémentation automatique, extension développée par Alain de la Chaume, qui n'est pas installée par défaut, qui garde trace de toutes les versions précédentes d'un même fichier.

manipuler du ODT avec Word, c'est le mal

Je ne suis pas utilisateur de la suite Microsoft...
Ce qui est sûr, c'est qu'une bonne part des corruptions de fichier vient de l'arrachage prématuré des clés USB, de l'insertion d'images trop volumineuses dans les fichiers textes (phénomène accentué par la taille des photos des APN et des Smartphones actuels), d'allers-retours incessants entre des logiciels dont les filtres d'import/export ne sont pas parfaits, de la généralisation des documents compressés qui ajoute une couche de risques supplémentaire...
Cordialement,
Jean-Louis

[kratosangel]

Mince, je croyais que c'était la même chose.
Cette extension est dépassée par contre pour Libre Office à jour ?
Bon à savoir les causes probables de problèmes.

Par contre, ce que je n'arrive pas à comprendre, c'est pourquoi un fichier, qu'elle ouvre sans problème sans aucune modification et fonctionne, devient soudainement corrompu et irrécupérable quelques minutes/heures après ?
A priori, un document ne peut devenir corrompu que s'il y a une manipulation effectuée non ? (nouvelle sauvegarde, déplacement ...)

[Dude]

Par contre, ce que je n'arrive pas à comprendre, c'est pourquoi un fichier, qu'elle ouvre sans problème sans aucune modification et fonctionne, devient soudainement corrompu et irrécupérable quelques minutes/heures après ?

Ta question montre que tu n'as pas lu le lien donné par Jean-Louis sur les conseils.
Les raisons d'une corruption y sont évoqués.

[kratosangel]

Bonjour,

Si, j'ai bien lu cet article et rien ne mentionne justement le cas précis que j'ai évoqué dans cet article, d'où ma question.
J'imagine que je n'ai pas bien expliqué ce dernier cas et qu'il a donc pu prêter à confusion :

- Le fichier concerné était sur le disque dur de l'ordinateur, pas sur clé USB
- Le fichier ne contenait pas d'image
- L'ordinateur n'a pas été arrêté subitement
- Le fichier n'a nullement été modifié : juste ouvert, puis refermé, aucune modification
- Le fichier était corrompu après cette ouverture sans modification

J'espère avoir mieux expliqué ce cas qui n'est pas mentionné dans l'article car, comme je le disais au-dessus, l'article ne mentionne que des cas où une modification a été faite sur le fichier.

[Scrat]

Bonjour.

Le dernier fichier mis en ligne n'est pas récupérable.

Et à partir du moment où un document est ouvert, même si on n'y fait aucune modification, le moindre incident (micro-coupure par exemple) peut affecter son contenu sur le disque.

Donc, pour se mettre à l'abri, il faut MULTIPLIER LES COPIES DE SAUVEGARDE. L'extension de sauvegarde incrémentale est faite pour ça.

A+

[Jean-Louis Cadeillan]

Bonjour,
Si tu es certain que ce fichier n'a pas été modifié (sur ce terme, il peut y avoir ambiguïté : par exemple, la fermeture d'un fichier protégé par mot de passe demande l'enregistrement même sans modification), alors ça risque d'être plus plus grave. L'intégrité du disque dur en question peut être en cause. Si je suppose que l'OS de l'ordi de ta compagne est Win 7, tu as un outil pour vérifier cela : clic droit sur l'unité de stockage (la partition) concernée > Propriétés > Outils > Vérifier maintenant. Pense aussi à l'environnement électromagnétique de ton disque dur, les boîtiers d'ordi ne sont pas étanches à 100% (exemple : un haut-parleur (qui contient un électro-aimant puissant) à proximité). Refais également un scan antivirus complet de cet ordi.
Il peut y avoir bien d'autres causes de corruptions alliant le physique et le logiciel : par exemple, tu peux avoir lancé une défragmentation (ou bien programmé une défragmentation) du DD et il se produit une microcoupure pendant le process, événement que tu ne percevras même pas. Selon le système de fichiers, l'OS peut implémenter une réparation spontanée (par exemple pour NTFS) du balisage des fichiers, c'est un avantage la plupart du temps, mais si tu as une alimentation électrique non sécurisée (pas d'onduleur), avec des sauts de tension, cela risque d'altérer davantage l'intégrité du DD. La tolérance aux pannes est un souci constant de l'informatique, mais il n'y a pas de système sûr à 100% (même les techniques RAID sur serveurs) . Il faut avoir conscience de cela. La sauvegarde quotidienne (incrémentée pour les fichiers les plus sensibles) sur unités séparées (y compris physiquement) contribue à fiabiliser les données. Enfin il faut savoir qu'il y a une démagnétisation lente, spontanée, des disques durs, chaque réécriture remagnétisant le bit correspondant...
Cordialement,
Jean-Louis

[kratosangel]

Bonjour.

Le dernier fichier mis en ligne n'est pas récupérable.

Et à partir du moment où un document est ouvert, même si on n'y fait aucune modification, le moindre incident (micro-coupure par exemple) peut affecter son contenu sur le disque.

Donc, pour se mettre à l'abri, il faut MULTIPLIER LES COPIES DE SAUVEGARDE. L'extension de sauvegarde incrémentale est faite pour ça.

A+

Merci d'avoir essayé et tant pis
C'est quand même étrange une micro coupure pour un disque dur par contre :/
Cette extension date de 2014, est-elle toujours viable pour Libre Office 6.x ?

@Jean-Louis : Je vois, c'est également probable car son ordinateur concerné était en fin de vie (port ethernet foutu, un seul USB sur 3 qui fonctionne ...) et des bugs.
Avec des défragmentations faites, possible que le HDD lâche également.
Finalement, madame dans son désespoir a achevé le PC et a donc dû en racheter un autre x) (fort heureusement, c'était prévu de longue date).
En espérant que ça ne se reproduise pas.

Merci encore pour votre aide et vos conseils.

[Jean-Louis Cadeillan]

Bonsoir,

Cette extension date de 2014, est-elle toujours viable pour Libre Office 6.x ?

Je n'ai pas la 6.3, mais en 6.2, pas de problème. Pense à installer la bonne extension (pour LibO) : la acIncrSav-L-2.1.oxt
Cordialement,
Jean-Louis

[kratosangel]

Ok ça marche merci !
J'ai vu aussi des trucs cool avec AOEMEI Backuper pour faire des backup, voire des synchros automatiques vers des Cloud ou autres partitions ou clé USB ou disque dur externe.
Bref, pas mal de sécurités différentes pour éviter ce genre de mésaventures à l'avenir ...

Merci encore à tous pour vos interventions, de votre aide et vos conseils.

[Libre0fficeFR]

On a été informé par Cyril du souci rencontré par Kratosangel.

On s'est penché plus en détail, et il apparait que les limites définies par le local header du fichier styles.xml est incorrect, si bien que lorsque vous demandez d'extraire le content.xml, c'est en réalité styles.xml qui est extrait. Corriger les limites et supprimer les caractères de fin de flux permettent de retomber sur une archive valide.

Avant:

Screenshot_20190827_160035.jpg

Après:

Screenshot_20190827_155535.jpg

Comprendre la structure de données du format ZIP est assez simple en soi: https://en.wikipedia.org/wiki/Zip_(file ... #Structure

Dans tous les cas, nous sommes toujours occupés à chercher une solution permettant de bypasser la vérification du CRC de content.xml afin de pouvoir récupérer son contenu dans son entièreté.

Dans tous les cas, il semblerait en effet que les données ait été corrompue par l'écriture malencontreuse de caractères de fin de flux dans l'archive même: un driver défectueux de Windows 7, la mise en veille du périphérique, un antivirus peu scrupuleux,... sont autant de raisons qui pourraient justifier ces caractères.

^WG

[kratosangel]

Bonjour,

Merci beaucoup pour avoir passé autant de temps sur ce cas !
Je vois qu'il y a eu des choses positives de faites même si ce n'est pas encore gagné pour autant, et le problème de la clé USB confirmé :/

Du coup il y a un espoir de récupérer le contenu de content.xml ou trop compliqué ?

[Dredd]

Bonjour,

J'ai du mal à suivre. Tantôt tu annonces que le document était sur clef USB et dans d'autres messages, tu dis le contraire.

2 fichiers ODT qui sont devenus soudainement corrompus (travail directement sur la clé USB ...).

- Le fichier concerné était sur le disque dur de l'ordinateur, pas sur clé USB

et le problème de la clé USB confirmé :/

[kratosangel]

Bonjour,

Oui désolé, ce n'est pas très clair.
En fait, les premiers fichiers (les 3 postés) étaient sur clé USB. Après coup, il y en a eu un 4e de corrompu qui lui était sur disque dur (il n'étais pas important à récupérer donc il n'est pas posté ici) et c'est ce cas qui m'inquiétait un peu sur la corruption sans modification.

[micmac]

Bonjour,

Je rappelle que ce sujet a été déclaré résolu.
Si tel n'est pas le cas, merci d'éditer le titre du premier message, enlever la balise [Résolu] et décocher la coche verte à la condition de rester sur le sujet initial.

[Scrat]

Du coup il y a un espoir de récupérer le contenu de content.xml ou trop compliqué ?

Je rappelle que le dernier fichier mis en ligne n'est pas récupérable parce que je n'arrive pas à extraire le content.xml avec les outils dont je dispose, et je suis bien incapable d'aller bidouiller directement dans le fichier zip. Si certains arrivent à l'extraire, ils peuvent tenter de le réparer avec l'utilitaire de réparation XmlRepar décrit dans le tutoriel.

A+

[Libre0fficeFR]

Du coup il y a un espoir de récupérer le contenu de content.xml ou trop compliqué ?

Bonsoir,

Pas de souci. Tenter de récupérer davantage nécessiterait encore plus de temps que passé jusqu'à présent, sans aucune certitude de récupération. C'est pourquoi, on pense que le jeu n'en vaut peut-être pas la chandelle. Ceci dépend bien évidemment de la nature critique ou pas des informations contenues dans ce document.

^WG

[kratosangel]

D'accord, je comprends bien que ça peut ne pas être drôle en effet.
Il ne s'agit pas tant d'informations critiques mais plutôt de nombre important d'heures de travail pour un seul de ces fichiers, si cela était possible, c'est le "séance 6 et 7" du premier message qui est vraiment le plus important.
Pour le reste, ça ne vaut pas la peine de vous en demander autant.

Donc si c'est possible de faire une tentative pour ce "séance 6 et 7", ce serait cool, mais si ça représente trop de travail je comprendrais tout à fait.

[osnola]

Bonjour,
séances 6 et 7.odt contient bien un fichier content.xml, mais il semble corrompu : il est possible de forcer l'extraction de cette zone et sa décompression, mais la décompression avec inflate/zip s'arrête après avoir décompressé 25859 caractères sur les 124851 originaux. C'est bien trop peu pour récupérer une partie du contenu du fichier, seulement une partie de la zone office:automatic-styles (ce qui ne sert à rien).

Côté seduta 1.odt, c'est pire, la zone où devrait se trouver le fichier content.xml est corrompue dès le départ, ie. même après avoir tenté de corriger le header de cette zone, je n'arrive à rien décompresser avec inflate/zip :-~

[kratosangel]

Bonjour,

Mince, pas de chance alors, dommage
Merci beaucoup d'avoir tout de même essayé malgré la pénibilité que ça représentait, c'est sympa !