[Abandonné] Récupération d'un fichier effacé

Gael de Sailly · Le 02/08/2017, à 18:17

Bonjour,

Hier j'ai réinstallé Ubuntu 16.04 sur mon ordi portable, mais voulant faire une installation propre, j'ai sciemment reformaté la partition et supprimé tous les fichiers. J'avais fait une copie de sauvegarde partielle, juste les fichiers que je considère utiles (je voulais en profiter pour faire le ménage parce que c'était le bazar), mais voilà j'en ai oublié un, qui se trouve être mon "journal" où je résume ma journée tous les soirs. C'est quelque chose de très important pour moi. Le dernier backup date du 25/5 donc j'en ai perdu plus de 2 mois.

La partition est actuellement occupée à 7%, donc le fichier n'a probablement pas été effacé. J'ai essayé la récupération avec Foremost, mais j'ai vite arrêté la procédure quand j'ai compris qu'il reconnaissait les fichiers selon leur signature.

J'ai éteint l'ordinateur, et je ne veux plus rien faire tant que je n'ai pas d'idée précise de comment faire pour retrouver ce truc. (si mon cas est désespéré je préfèrerais le savoir tout de suite…)

Ce que je sais sur ce fichier :

Il a été créé le 15/02/16 et modifié tous les jours jusqu'au 31/07/17
Il s'appelle "journal", n'a pas d'extension
C'est un fichier texte brut non compressé
Il commence par "Lundi 15 février 2016:", au caractère près
Il fait dans les 200 ko.

J'envisage de créer une image disque sur un disque dur externe, il reste pas mal de place. Mais après, comment récupérer un fichier comme ça ? Est-ce qu'on peut rechercher du texte directement dans le fichier image disque ? (Je suppose que c'est plus compliqué que ça…)

Quelqu'un peut-il m'aider ?
Merci d'avance.

Dernière modification par Gael de Sailly (Le 06/08/2017, à 10:33)

nam1962 · Le 02/08/2017, à 18:43

Effectivement, il faudra mieux passer par une session live.
J'aurais tendance à te suggérer photorec : https://doc.ubuntu-fr.org/photorec

?? · Le 02/08/2017, à 18:51

Bonjour
Tu connais déja plein de choses pour ce fichier
D'abord sa taille environ 200Ko
Puis aussi son type car tu devais certainement utiliser openoffice (gedit ?) Cela n'a rien à voir avec son extension (.doc) ( .txt ????)
Puis aussi un portion du contenu.

Tu peux rapidement savoir si cette zone est encore trouvable dans la partition avec la commande en remplaçant la valeur N par ce qui convient

sudo dd if=/dev/sdaN bs=16065 | hexdump -C | grep 'Lundi 15 février 2016'

à partir du type, l'outil va fabriquer l'extension.
Tu as commencé avec foremeost, mais tu aurais pu aussi utiliser photorec qui fonctionne aussi sur le même principe.

Bien entendu, ce qui est récupéré ne doit pas être écrit dans la partition.

Donc tu continues avec foremost (Je ne le connais pas). Lorsqu'il aura tout trouvé, tu ventiles: A la porte les fichiers .sh les fichiers .jpg les fichiers .mp3 etc...

Puis dans les fichiers qui resteront, un petit tri: à la porte les fichiers < 10 Ko et les fichiers plus grands que 1 Mo.

Après, il ne te restera plus qu'à lire ou rechercher le libellé en question... Lorsqu'il sera trouvé, on doit arriver assez facilement à trouver le nouveau nom qui a été affecté..

Dernière modification par ?? (Le 02/08/2017, à 19:25)

jamesbad000 · Le 02/08/2017, à 19:05

Bonjour.

Gael de Sailly a écrit :

si mon cas est désespéré je préfèrerais le savoir tout de suite

C'est juste totalement incertain...

Faire une image disque est effectivement une bonne approche.

Dans tout les cas: il ne faut pas démarrer ce PC directement, à moins que la partition en question n'abrite ni la racine, ni le répertoire /home ni tout autre répertoire standard linux (/var /tmp...)

Et donc travailler à partir d'un live cd. Histoire d'éviter une risque d'écrasement supplémentaire...

Gael de Sailly a écrit :

Est-ce qu'on peut rechercher du texte directement dans le fichier image disque ? (Je suppose que c'est plus compliqué que ça…)

Non, chercher du texte dans une image disque, comme sur le disque lui même d'ailleurs n'est pas si compliqué que ça. En revanche retrouver un fichier entier peut être une vraie gageure.
Néanmoins, vu la faible taille, et particulièrement si la partition était en ext4, il y a de bonnes chance que le fichier soit en un seul bloc...

Donc déjà démarrer sur un live cd. Je reviens ultérieurement avec une méthode précise...

Et donner le retour de

sudo lsblk -o size,name,fstype,label,mountpoint

Histoire que j'ai une vision générale du disque et de ce qu'il contient

Edit : Précise aussi avec quoi tu éditais ce fichier !!

Dernière modification par jamesbad000 (Le 02/08/2017, à 19:09)

Gael de Sailly · Le 02/08/2017, à 22:52

Merci de vos réponses

Une question débile d'ordre pratique : j'ai un live CD (celui avec lequel je viens d'installer Ubuntu), mais le machin truc qui s'ouvre pour mettre le disque ne marche pas quand l'ordi est éteint… donc comment je met le CD sans booter le disque dur ?
(en passant c'est un SSD de 120 Go)

Si je fais une image disque c'est utilisable de la même façon ? Du coup je pourrais à nouveau utiliser mon ordi ?

jamesbad000 a écrit :

Edit : Précise aussi avec quoi tu éditais ce fichier !!

J'utilisais gedit, et donc c'est un fichier texte brut (text/plain).

?? · Le 02/08/2017, à 23:09

Bonsoir
La solution est de mettre du courant électrique, puis de faire très vite pour ouvrir le le boîtier et d'y insérer le cdrom au risque de se faire coincer les doigts si on ne va pas assez vite!

Dernière modification par ?? (Le 02/08/2017, à 23:09)

jamesbad000 · Le 03/08/2017, à 01:01

Gael de Sailly a écrit :

comment je met le CD sans booter le disque dur ?

Plusieurs solutions possibles
soit déplier un trombone standard, et l'introduite dans l'orifice d'ouverture manuelle qui se trouve sur le tiroir du lecteur. (actionne un levier à l'intérieur du tiroir)

Soit mettre sous tension, et
interrompre le démarrage en activant une touche d'accès au menu bios ou choix de périphérique évoquée ci-dessous. Ou mettre hors tension juste après l'ouverture du tiroir.
Ou provoquer l'affichage du menu grub en maintenant enfoncé la touche échap...

Dans tout les cas, il faut déjà être certain qu'il démarre sur le cd en priorité (réglage du bios préalable, ou accès à un menu bios de choix de périphérique de démarrage, évoqué ci-dessus

S'assurer de la maîtrise de la procédure de mise hors tension forcée, au cas ou ça démarre quand même à partir du disque.
(en général appuis long sur le bouton de mise sous tension)
Pas la peine de trop stresser quand même, pendant une bonne partie du démarrage, les partitions sont en lecture seule...

Si je fais une image disque c'est utilisable de la même façon ? Du coup je pourrais à nouveau utiliser mon ordi ?

Oui. En même temps, ça ne devrait pas immobiliser plus longtemps ton pc de faire une recherche directement sur le disque.

J'utilisais gedit, et donc c'est un fichier texte brut (text/plain).

Ok, ça ne laisse aucun doute sur la nature de ce qu'on cherche.

Dernière modification par jamesbad000 (Le 03/08/2017, à 01:04)

Gael de Sailly · Le 03/08/2017, à 10:42

Bonjour,

J'ai essayé d'introduire le CD rapidement mais mon ordi démarre vraiment trop vite (7-8 secondes). Je n'ai pas pu l'empêcher de booter mais je ne pense pas qu'il ait écrasé une grande quantité de données, surtout si je n'ai pas démarré de session. Enfin j'espère…

J'ai mis le disque et redémarré aussitôt. Je n'arrive pas à cloner le disque dur en image iso par dd, le fichier bloque à 4 294 967 295 octets.

J'ai fait la commande conseillée par jamesbad000 :

ubuntu@ubuntu:~$ sudo lsblk -o size,name,fstype,label,mountpoint
  SIZE NAME   FSTYPE   LABEL                    MOUNTPOINT
931,5G sdb                                      
931,5G └─sdb1 vfat     MY BOOK                  /media/ubuntu/MY BOOK
  1,5G sr0    iso9660  Ubuntu 16.04.2 LTS amd64 /cdrom
  1,4G loop0  squashfs                          /rofs
119,2G sda                                      
  1,9G ├─sda5 swap                              [SWAP]
117,3G └─sda1 ext4

sdb1 c'est le disque dur externe où j'avais essayé de mettre l'image ISO.

Je viens de lancer ceci :

sudo dd if=/dev/sda1 bs=16065 | hexdump -C | grep 'Lundi 15 février 2016'

et ça tourne depuis au moins 20 minutes sans résultat.

Gael de Sailly · Le 03/08/2017, à 11:22

Il a fini et m'a retourné ça :

ubuntu@ubuntu:~$ sudo dd if=/dev/sda1 bs=16065 | hexdump -C | grep 'Lundi 15 février 2016'
7841573+1 enregistrements lus
7841573+1 enregistrements écrits
125974872064 bytes (126 GB, 117 GiB) copied, 2864,32 s, 44,0 MB/s

jamesbad000 · Le 03/08/2017, à 11:31

Normal. Le texte est trop long pour tenir sur une ligne de la commande hexdump.
edit 2: En plus la représentation du caractère accentué (2 octets en UTF8) va donner .. dans le résultat de hd

00874800  4c 75 6e 64 69 20 31 35  20 66 c3 a9 76 72 69 65  |Lundi 15 f..vrie|
00874810  72 20 32 30 31 36 0a 00  00 00 00 00 00 00 00 00  |r 2016..........|

on va procéder en 2 étapes:
Extraire la liste des emplacements contenant la chaine (les emplacements trouvés seront affichés et stockés sur le disque externe dans le fichier listRecup

sudo grep -b -a -o "Lundi 15 février 2016" /dev/sda1 | cut -d: -f1 | tee "/media/ubuntu/MY BOOK/listRecup"

Récupérer 220Ko à partir des emplacements trouvés, et placer le résultat dans un fichier recupXXXXX sur le disque externe

cat "/media/ubuntu/MY BOOK/listRecup" | sudo xargs -n 1 -I {} dd if=/dev/sda1 of="/media/ubuntu/MY BOOK/recup{}.txt" bs=1k count=220 iflag=skip_bytes skip={}

Humpf. J'ai oublié l'option -o dans la commande grep. Corrigé ci-dessus. (peut éventuellement améliorer la précision)

Edit 3: Le chemin d'accès contenant des espaces, il faut aussi ajouter les guillemets... (corrigé ci-dessus)

Dernière modification par jamesbad000 (Le 03/08/2017, à 18:41)

Gael de Sailly · Le 03/08/2017, à 13:32

Merci. J'ai fait le premier, ça fait 1h24 que ça tourne mais l'ordi ne réagit absolument pas… je ne peux même plus déplacer la souris, et le CD tourne à plein régime alors que ce n'est pas lui qui est lu, normalement.

J'ai mis ça :

sudo grep -b -a -o "Vendredi 26 mai" /dev/sda1 | cut -d: -f1 | tee "/media/ubuntu/MY BOOK/listRecup"

J'ai préféré rechercher le 26/5 pour avoir la fin du fichier. (Si par hasard le fichier est en 2 morceaux ou plus et que je ne trouve que le début, ça m'intéresse pas, je l'ai déjà)

?? · Le 03/08/2017, à 14:01

Bonjour.
Sauf erreur de ma part
C'est normal que cela tourne encore. Je n'ai pas trouvé d'option pour indiquer à la commande grep la taille de l'unité de lecture.. C'est donc probablement 512 qui est retenu au lieu de 16384 ( J'ai modifié la doc pour qu'il y ai pas écrit 16065!!) donc 16 fois plus de temps

De plus tu as 16 fois plus de chances de ne pas trouver le libellé s'il est écrit à cheval sur deux blocs car il n'est plus en tête du fichier.

jamesbad000 · Le 03/08/2017, à 14:14

oui, c'est une bonne idée de chercher à partir de ce qui manque.
Par contre je vois pas non plus pourquoi le cd est sollicité en permanence.

?? a écrit :

De plus tu as 16 fois plus de chances de ne pas trouver le libellé s'il est écrit à cheval sur deux blocs car il n'est plus en tête du fichier.

Il n'y a pas de notion d'alignement sur des blocs pour la recherche avec grep. Et encore moins de notion de tête de fichier sur un périphérique de bloc.
Et en plus, j'ai bien pris soin de faire un test avec un texte qui commence sur la 2ème ligne d'un fichier.
Quant au "problème" de vitesse. Tout reste à prouver.

Dernière modification par jamesbad000 (Le 03/08/2017, à 14:16)

jamesbad000 · Le 03/08/2017, à 14:23

Pour en revenir à ce problème de cd qui tourne à fond, et tout le reste bloqué...
Sais tu combien tu as de mémoire sur cette machine ?

jamesbad000 · Le 03/08/2017, à 16:24

Bon je viens de faire un petit test: grep directe, versus dd...
résultat: Dans le meilleurs des cas, dd est environ 2 fois plus rapide, à condition d'enlever hexdump (J'ai interrompu le run avec hexdump après 40 mn d'attente, et il n'en était qu'à 4Go sur 12... hexdump prenant 100% sur une CPU quand grep et dd sont à 4,5 et 1 %)

Donc la commande que tu exécute ne devrait pas durer nettement plus longtemps que la première tentative avec dd (un peu moins d'une heure).
Si bien que je pense qu'il faut envisager d'interrompre l'opération, et voir déjà si le cd se calme. Ou s'il y a un autre problème qui accapare toute la CPU

Je met le résultat de mes test (Noter que plusieurs occurrences sont trouvées, non pas parce que je tiens moi aussi un journal, mais parce que j'ai fait plusieurs test qui ont laissé des traces...)

fred@Extensa:~$ date; sudo grep -b -a -o  "Lundi 15 février 2016" /dev/sdb7 | cut -d: -f1 | tee listRecup; date
jeudi 3 août 2017, 15:14:19 (UTC+0200)
5369637973
5369638377
5369639251

jeudi 3 août 2017, 15:18:22 (UTC+0200)

fred@Extensa:~$ date; sudo dd if=/dev/sdb7 bs=16384 | hexdump -C | grep 'Lundi 15 février 2016'; date
jeudi 3 août 2017, 15:19:26 (UTC+0200)
^C295530+0 enregistrements lus
295529+0 enregistrements écrits
4841947136 octets (4,8 GB) copiés, 2225,8 s, 2,2 MB/s

fred@Extensa:~$ date; sudo dd if=/dev/sdb7 bs=16384 | grep 'Lundi 15 février 2016'; date
jeudi 3 août 2017, 16:11:32 (UTC+0200)
Fichier binaire (entrée standard) correspondant
jeudi 3 août 2017, 16:13:02 (UTC+0200)

Dernière modification par jamesbad000 (Le 03/08/2017, à 16:25)

Gael de Sailly · Le 03/08/2017, à 18:34

La première tentative a duré 50 minutes et n'a rien donné d'intelligible (pour moi), et la deuxième est en cours depuis 6h20. Vous confirmez que je peux l'arrêter ? Je m'attendais à ce que ça dure 16 fois plus longtemps.
EDIT : et la mémoire de mon bidule c'est 1,8 Go.

Dernière modification par Gael de Sailly (Le 03/08/2017, à 18:36)

jamesbad000 · Le 03/08/2017, à 18:40

Non en fait ça devrait plutôt être plus rapide d'après mes test. En tout cas, je ne vois pas de bonnes raison que ça dure 6h et avec le cd qui tourne à fond.

Ceci dit, il pourrait être utile avant d'interrompre, de tenter d'ouvrir un autre terminal et de capturer le résultat de la commande top
(ressortir par appuis sur Q une vingtaine de seconde après lancement pour pouvoir copier le résultat...)

Edit: Préciser aussi si le cd s'arrête une fois la commande interrompue

Dernière modification par jamesbad000 (Le 03/08/2017, à 18:45)

Gael de Sailly · Le 03/08/2017, à 18:45

jamesbad000 a écrit :

il pourrait être utile avant d'interrompre, de tenter d'ouvrir un autre terminal et de capturer le résultat de la commande top
(ressortir par appuis sur Q une vingtaine de seconde après lancement pour pouvoir copier le résultat...)

Je ne peux pas, il est complètement bloqué. Je ne peux même plus bouger la souris, et même l'heure est restée à 12h08…

jamesbad000 · Le 03/08/2017, à 18:48

Mouais. Complètement planté quoi. Avec un peu de chance, ça n'a pas grand chose à voir avec ce qu'on fait.
Tenter ctrl C sur le terminal, de façon répétée. Et si ça ne s'arrête pas après une dizaines de tentatives. Il n'y aura plus que la mise hors tension forcée...

Gael de Sailly · Le 03/08/2017, à 18:54

Mis hors tension. Je ne tente plus rien aujourd'hui, je verrais demain.

jamesbad000 · Le 03/08/2017, à 19:03

Ok. En principe, sauf si on a un problème lié au live cd. Il n'y a pas de raison que ça marche chez moi, et pas chez toi.

En tout cas, en cas de relance, si le cd repart en vrille et surtout si l'horloge reste scotchée pendant 10 minutes, ce n'est pas la peine d'attendre... Il faudra soit trouver une autre formulation de la commande, soit utiliser une autre version de live cd...
A cet égare il sera utile de donner le retour de

sudo lsb_release -a

Dernière modification par jamesbad000 (Le 03/08/2017, à 19:04)

?? · Le 03/08/2017, à 19:41

Bonsoir jamesbad000

La commande que j'ai proposé, je l'ai sortie de la doc ubuntu.
Je viens de corriger à trois endroits. De plus le temps d'exécution est très long... La lecture s'effectue à environ 4 Mo/s ce qui fait une énorme attente pour un résultat négatif. Ce qui semble logique vu ce que tu as dis sur la longueur de la zone cherchée ==> Reformatage par la commande hexdump en toute petite entité.
Il serait bon que tu jettes un coup d'oeil à cette partie de doc et au besoin que tu la vires si elle te semble ridicule.

C'est le paragraphe 5.6 de https://doc.ubuntu-fr.org/dd

https://doc.ubuntu-fr.org/dd a écrit :

Faire une recherche de chaines de caractères dans une partition tout entière
Supposons que vous souhaitiez trouver si votre petite amie vous trompe, a des cybers amants, ou se conduit mal avec son ordinateur. Même si l'ordinateur est protégé par un mot de passe, vous pouvez booter avec le CD: http://www.efense.com/helix ou un autre live-CD et chercher la chaine de caractères dans la partition entière, en utilisant la commande grep:
dd if=/dev/sda2 bs=16384| hexdump -C | grep 'je ne l aime vraiment plus'
Cherchera dans toute la partition la chaîne de caractères (pas d'accents) spécifiée entre les guillemets (utilisez éventuellement les options de grep: avec, disons, grep -3 'chaine' vous auriez un peu plus de contexte affiché pour chaque résultat de recherche). Chercher plusieurs fois dans une partition entière peut être fastidieux. Cette commande particulière sur les chaines de caractères imprime le résultat de la recherche sur l'écran, avec l'offset où il se trouve dans la partition. dd travaille en système décimal. L'offset des disques travaille en hexadécimal. Disons que vous trouvez la chaine de caractères dans votre partition à l'offset 0x020d0d90h. Vous convertissez cela en décimal avec l'une des nombreuses calculatrices trouvées sur Linux. Ceci est l'offset décimal 34409872. Divisé par 512 par secteur, nous obtenons 67206,78125.

qui plus est la commande initiale contenait une erreur de codif et une taille de lecture un peu bizarre que je n'étais permis de rectifier ce jour

dd if=/dev/sda2 bs=16065| hexdump -C | grep 'je ne l'aime vraiment plus'

J'avais aussi ajouté (pas d'accents)

Dernière modification par ?? (Le 03/08/2017, à 20:52)

?? · Le 03/08/2017, à 20:51

Sacrément efficace cette commande

sudo grep -b -a -o "VendrediA26BmaiC" /dev/sda7 | cut -d: -f1 | tee "$HOME/listRecup"

Dans mon contexte: Partition de 50 Go parcourue en 9 minutes et libellé retrouvé. Il était pourtant bien à cheval sur deux blocs.

$ date
jeudi 3 août 2017, 20:47:43 (UTC+0200)
sudo grep -b -a -o "VendrediA26BmaiC" /dev/sda7 | cut -d: -f1 | tee "$HOME/listRecup"
11069436406
20983718234
20983718436
21655942619
21657121270
$ date
jeudi 3 août 2017, 20:56:54 (UTC+0200)
$ df -Th |grep sda7
/dev/sda7        ext4        50G     20G   27G  43% /
$ 
$

et quelques fichiers générés pour ouverture par gedit par une commande que je ne comprend pas trop

Dernière modification par ?? (Le 03/08/2017, à 21:03)

moko138 · Le 03/08/2017, à 22:11

Gael de Sailly a écrit :

Je n'arrive pas à cloner le disque dur en image iso par dd, le fichier bloque à 4 294 967 295 octets.
J'ai fait la commande conseillée par jamesbad000 :
ubuntu@ubuntu:~$ sudo lsblk -o size,name,fstype,label,mountpoint
SIZE NAME FSTYPE LABEL MOUNTPOINT
931,5G sdb
931,5G └─sdb1 vfat MY BOOK /media/ubuntu/MY BOOK
sdb1 c'est le disque dur externe où j'avais essayé de mettre l'image ISO.

1) Normal :
une iso c'est un fichier (même quand c'est l'image de toute une partition).
Or la vfat/fat32 ne sait pas gérer de fichier plus grand que (environ) 4 Go. Et tu as atteint la limite.

2) Aux moments où ça a planté,
étais-tu en train de retenter un clonage vers ton "MY BOOK" ?

jamesbad000 · Le 04/08/2017, à 01:33

?? a écrit :

Il serait bon que tu jettes un coup d'oeil à cette partie de doc et au besoin que tu la vires si elle te semble ridicule.

Ce n'est pas vraiment ridicule, mais c'est assez approximatif. Quoique certaines tournures de phrase laissent perplex. Comme "L'offset des disques travaille en hexadécimal"
Dans ce pays on se plein beaucoup du plombier Polonais, ou du lévrier Afghan qui prennent notre travail. Mais l'offset, personne ne l'a vu venir celui là...

Enfin oui tu as raison, il faudrait que je m'y mette. En fait j'avais déjà fait quelques retouches. Mais finalement, il faudrait réécrire toute cette page.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/08/2017, à 18:17

[Abandonné] Récupération d'un fichier effacé

#2 Le 02/08/2017, à 18:43

Re : [Abandonné] Récupération d'un fichier effacé

#3 Le 02/08/2017, à 18:51

Re : [Abandonné] Récupération d'un fichier effacé

#4 Le 02/08/2017, à 19:05

Re : [Abandonné] Récupération d'un fichier effacé

#5 Le 02/08/2017, à 22:52

Re : [Abandonné] Récupération d'un fichier effacé

#6 Le 02/08/2017, à 23:09

Re : [Abandonné] Récupération d'un fichier effacé

#7 Le 03/08/2017, à 01:01

Re : [Abandonné] Récupération d'un fichier effacé

#8 Le 03/08/2017, à 10:42

Re : [Abandonné] Récupération d'un fichier effacé

#9 Le 03/08/2017, à 11:22

Re : [Abandonné] Récupération d'un fichier effacé

#10 Le 03/08/2017, à 11:31

Re : [Abandonné] Récupération d'un fichier effacé

#11 Le 03/08/2017, à 13:32

Re : [Abandonné] Récupération d'un fichier effacé

#12 Le 03/08/2017, à 14:01

Re : [Abandonné] Récupération d'un fichier effacé

#13 Le 03/08/2017, à 14:14

Re : [Abandonné] Récupération d'un fichier effacé

#14 Le 03/08/2017, à 14:23

Re : [Abandonné] Récupération d'un fichier effacé

#15 Le 03/08/2017, à 16:24

Re : [Abandonné] Récupération d'un fichier effacé

#16 Le 03/08/2017, à 18:34

Re : [Abandonné] Récupération d'un fichier effacé

#17 Le 03/08/2017, à 18:40

Re : [Abandonné] Récupération d'un fichier effacé

#18 Le 03/08/2017, à 18:45

Re : [Abandonné] Récupération d'un fichier effacé

#19 Le 03/08/2017, à 18:48

Re : [Abandonné] Récupération d'un fichier effacé

#20 Le 03/08/2017, à 18:54

Re : [Abandonné] Récupération d'un fichier effacé

#21 Le 03/08/2017, à 19:03

Re : [Abandonné] Récupération d'un fichier effacé

#22 Le 03/08/2017, à 19:41

Re : [Abandonné] Récupération d'un fichier effacé

#23 Le 03/08/2017, à 20:51

Re : [Abandonné] Récupération d'un fichier effacé

#24 Le 03/08/2017, à 22:11

Re : [Abandonné] Récupération d'un fichier effacé

#25 Le 04/08/2017, à 01:33

Re : [Abandonné] Récupération d'un fichier effacé

Pied de page des forums