Fusion de deux fichiers

Bonjour,

Je rencontre un problème assez complexe avec un fichier texte, aussi je vais essayer de faire simple.

Il y a un certain temps, j’ai créé un document texte au format .docx - appelons le “A” - via l’application Google Docs (sur un smartphone).
J’ai ensuite transéféré ce document sur une clé USB afin de le modifier via LibreOffice (sur un PC).
A présent, je viens d’ouvrir le fichier qui n’avait plus été consulté depuis plusieurs mois et le problème suivant est survenu :

  • LibreOffice affiche le message d’erreur : “Le fichier “A” est corrompu et ne peut donc être ouvert. LibreOffice peut essayer de réparer le document. […] L’exécution des macros est désactivée pour ce document. LibreOffice doit-il réparer le document ?”

  • En cliquant sur “oui”, le fichier s’ouvre mais son contenu n’a plus rien à voir avec le fichier “A”. Il semble que deux fichiers aient fusionné à un moment donné et que l’un se superpose à l’autre.

  • Sauf que - là est le complexe - le fichier “A” corrompu a une taille de 170 Ko tandis que le contenu qui s’affiche ne représente qu’une taille de 90 ko ! (j’ai copié-collé le contenu à l’écran pour l’enregistrer dans un fichier “B” et relever sa taille).

  • Après consultation du forum, j’ai tenté la récupération du fichier “A” via les commandes “zip -T” et “zip -FF”. Le résultat est le suivant :

$ zip -T A.docx
	zip warning: unexpected signature on disk 0 at 17191

	zip warning: archive not in correct format: A.docx
	zip warning: (try -F to attempt recovery)

zip error: Zip file structure invalid (A.docx)
$ zip -FF A.docx --out B.docx
Fix archive (-FF) - salvage what can
 Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
 copying: mimetype  (39 bytes)
 copying: Configurations2/images/Bitmaps/  (0 bytes)
 copying: Configurations2/accelerator/  (0 bytes)
 copying: Configurations2/floater/  (0 bytes)
 copying: Configurations2/toolpanel/  (0 bytes)
 copying: Configurations2/statusbar/  (0 bytes)
 copying: Configurations2/toolbar/  (0 bytes)
 copying: Configurations2/progressbar/  (0 bytes)
 copying: Configurations2/menubar/  (0 bytes)
 copying: Configurations2/popupmenu/  (0 bytes)
 copying: styles.xml  (2499 bytes)
 copying: manifest.rdf  (261 bytes)
 copying: meta.xml  (455 bytes)
 copying: settings.xml  (1668 bytes)
 copying: Thumbnails/thumbnail.png  (11444 bytes)
 copying: content.xml  (2453 bytes)
 copying: layout-cache  (28 bytes)
 copying: META-INF/manifest.xml  (319 bytes)
Central Directory found...
EOCDR found ( 1  21356)...
 copying: word/numbering.xml  (360 bytes)
Entry after central directory found ( 1  32768)...
 copying: word/settings.xml  (517 bytes)
 copying: word/fontTable.xml  (377 bytes)
 copying: word/styles.xml  (816 bytes)
 copying: word/document.xml  (3010 bytes)
 copying: word/_rels/document.xml.rels  (241 bytes)
 copying: _rels/.rels  (177 bytes)
 copying: word/theme/theme1.xml  (1580 bytes)
 copying: [Content_Types].xml  (300 bytes)
Central Directory found...
EOCDR found ( 1  41302)...
 copying: word/numbering.xml  (360 bytes)
Entry after central directory found ( 1  81920)...
 copying: word/settings.xml  (517 bytes)
 copying: word/fontTable.xml  (377 bytes)
 copying: word/styles.xml  (816 bytes)
 copying: word/document.xml  (3070 bytes)
 copying: word/_rels/document.xml.rels  (241 bytes)
 copying: _rels/.rels  (177 bytes)
 copying: word/theme/theme1.xml  (1580 bytes)
 copying: [Content_Types].xml  (300 bytes)
Central Directory found...
no local entry: word/numbering.xml
no local entry: word/fontTable.xml
no local entry: word/document.xml
no local entry: word/theme/theme1.xml
EOCDR found ( 1  90514)...

Le résultat est que le fichier B.docx (90 Ko) se retrouve complété d’une partie de texte, mais toujours sans aucun rapport avec le document d’origine “A”.

  • Par conséquent, comment lire les 80 Ko qui ont disparu du fichier “A” au “B” ?

Voilà, j’ai tenté d’être le plus clair possible. Si quelqu’un pouvait m’expliquer ce qui a causé la fusion de ces fichiers et surtout comment les séparer, je lui en serais infiniment reconnaissant.

Au plaisir de vous lire !

Bien cordialement,

pas sûr que la taille (Ko) sur disque soit le meilleur indicateur du contenu.
ça dit quoi en nombres de pages et caractères ?
ça donne quoi en .odt ?

:thinking:
ça pourrait indiquer de le filesystème sur la clé USB a vraiment souffert …
selon la capacité, l’OS, … ça peut être très fastidieux.
sous linux, faudrait commencer par qqchose comme :
dd if=/dev/usb/disk/sdX of=/path/to/backup.img bs=4M

ensuite, réviser les fondamentaux, par exemple : http://www-int.impmc.upmc.fr/impmc/Enseignement/ye/informatique/systemes/chap4/441.html
et s’attaquer à la résolution du puzzle :wink:

Bonjour,

Je vous remercie pour votre réponse,

Le fichier corrompu que LibreOffice parvient à ouvrir affiche 3 pages et 5,062 caractères (pour 170 Ko).
Le fichier obtenu avec la commande zip -FF affiche 4 pages et 7,050 caractères (pour 90 Ko).

Pour convertir en .odt, j’ai tenté en ligne de commande, sans succès :

$ pandoc A.docx -s -t odt -o a.odt
couldn't parse docx file: DocxError

puis via LibreOffice : obtention d’un fichier de 3 pages, 5,062 caractères, pour 37 Ko. (toujours sans rapport avec le document d’origine…)

Le problème remonte à plusieurs mois, je ne parviens pas à me souvenir de ce qui a pu se passer.

Je travaille depuis peu sous Debian et ne suis pas sûr d’avoir tout compris aux lignes de commande ci-dessus :

sur mon PC, je ne trouve pas l’emplacement /dev/usb/disk
J’ai essayé d’adapter les lignes de cette façon :

$ sudo dd if=/media/natma/6FDC-1522/A.docx of=/home/backup.img bs=4M
0+1 enregistrements lus
0+1 enregistrements écrits
171352 octets (171 kB, 167 KiB) copiés, 0,00108983 s, 157 MB/s

/6FDC-1522 correspond à ma clé USB

j’obtiens un fichier .img de 170 Ko, mais comment lire celui-ci ? faut-il créer une image disque de la clé USB entière et non du fichier A.docx ?

Si vous pouviez éclaircir ces derniers points…

En vous remerciant encore,

Cordialement,

yep.
(idéalement, il faut figer en readonly pour eviter d’agraver les pertes)

la commande [df](https://linuxcommand.org/lc3_man_pages/df1.html) donne le device correspondant au point de montage, donc
df /media/natma/6FDC-1522

ensuite pour aller à la pêche, faut s’inspirer d’outils comme 3 méthodes pour récupérer les fichiers supprimés d'un système de EXT4