# [Recovery] Récupérer dossier supprimé reiser3.6 (Résolu)

## boozo

'alute

Ai fait une cagade   :Laughing: 

Je me suis séparé très malencontreusement de mon rep de préférences mozilla dans un moment d'égarement au clavier. Bien sûr une fois n'est pas coutume, mon dernier backup /home date du "20070704" (arghl !!! j'ai failli m'étrangler il y a 2 nuits de celà)

Bon, me suis dit "pas grave" je vais me fendre d'un photorec par sécurité et d'un --rebuild-tree sur un disque externe histoire de retrouver mon précieux mais drame supplémentaire : les 2 méthodes ne sont gère utilisables toutes seules pour le commun des mortels. J'ai recouvré envion 32000 repertoires aléatoirement nommés avec sans doute au milieu de tout çà l'objet de mon méfait, et son contenu splité au gré des blocs et cylindres.

Et comment je m'y retouve maintenant ???   :Shocked: 

Je joue à coup de man grep et find depuis lors mais sans grand résultats je dois dire...

Si quelqu'un s'est déjà heurté à la chose et aurait une démarche/stratégie, un script/onelinerdelamortquituetout, ou toute autre idée pour m'éviter de choir à 2 mètres du bol de Sangria : un immense merci d'avance   :Cool: 

----------

## netfab

Tu parles de firefox ? en version 3 ? tu cherches à récupérer quoi exactement, tes bookmarks ?

Edit : par exemple si je lance le grep suivant dans le répertoire du profil firefox, j'obtiens les 5 derniers backups de mes bookmarks :

 *Quote:*   

> 
> 
> $ grep -R -l 'text/x-moz-place-container' *
> 
> bookmarkbackups/bookmarks-2011-02-11.json
> ...

 

Ces fichiers json étant importables depuis le gestionnaire de marque-pages de firefox.

----------

## boozo

@netfab : Oui tout à fait c'est principalement mon bookmark et si possible mes clés privés le reste n'a aucune importance

Sur la recup issue de photorec c'est inexploitable à mon sens ou alors je n'ai rien compris :

```
$ grep -R -l 'text/x-moz-place-container' * 

recup_dir.18/f0541936.txt

recup_dir.18/f0540936.txt

recup_dir.18/f0544032.txt

recup_dir.19/f0546904.txt

recup_dir.19/f0549840.txt

recup_dir.19/f0548656.txt

recup_dir.19/f0546872.txt

recup_dir.20/f0567090.imm

recup_dir.23/f0811856.doc

recup_dir.23/f0819392.txt

recup_dir.23/f0818816.txt

recup_dir.23/f0819568.txt

recup_dir.23/f0815864.txt

recup_dir.23/f0821080.txt

recup_dir.23/f0819640.txt

recup_dir.23/f0818424.txt

recup_dir.23/f0816088.doc

recup_dir.24/f0864440.txt

recup_dir.24/f0865768.html

recup_dir.24/f0866952.html

recup_dir.274/f7163152.h

recup_dir.338/f9007904.imm

recup_dir.354/f9632118.html

recup_dir.354/f9634230.txt

recup_dir.354/f9634278.txt

recup_dir.354/f9633006.txt

recup_dir.354/f9634308.txt

recup_dir.354/f9631198.txt

recup_dir.354/f9633182.txt

recup_dir.354/f9635086.txt

recup_dir.354/f9621742.txt

recup_dir.354/f9621790.txt

recup_dir.354/f9632854.txt

recup_dir.354/f9621310.txt

recup_dir.355/f9663982.txt

recup_dir.355/f9662798.txt

recup_dir.355/f9658382.txt

recup_dir.357/f9760615.txt

recup_dir.359/f9900519.txt

recup_dir.359/f9901142.txt

recup_dir.359/f9900640.txt

recup_dir.359/f9900678.txt

recup_dir.359/f9901272.txt

recup_dir.360/f9907912.txt

recup_dir.360/f9904816.txt

recup_dir.360/f9904896.txt

recup_dir.360/f9905544.txt

recup_dir.360/f9908008.txt

recup_dir.360/f9905560.txt

recup_dir.360/f9904288.txt

recup_dir.360/f9904358.txt

recup_dir.360/f9907936.html

recup_dir.360/f9904424.txt

recup_dir.360/f9903896.txt

recup_dir.360/f9904560.txt

recup_dir.360/f9907712.txt

recup_dir.360/f9907776.txt

recup_dir.360/f9922688.txt

recup_dir.360/f9905263.txt

recup_dir.360/f9922750.txt

recup_dir.366/f10121009.txt

recup_dir.366/f10121056.txt

recup_dir.366/f10162297.txt

recup_dir.366/f10120761.txt

recup_dir.366/f10120801.txt

recup_dir.366/f10121185.c

recup_dir.367/f10170581.txt

recup_dir.367/f10170805.txt

recup_dir.367/f10170907.txt

recup_dir.367/f10208224.txt

recup_dir.367/f10170685.h

recup_dir.367/f10208317.txt

recup_dir.367/f10208277.html

recup_dir.367/f10170453.txt

recup_dir.372/f10364640.txt

recup_dir.372/f10364680.txt

recup_dir.372/f10364736.txt

recup_dir.372/f10364216.txt

recup_dir.372/f10364408.html

recup_dir.374/f10461670.txt

recup_dir.374/f10461734.txt

recup_dir.425/f12361083.txt

recup_dir.425/f12363672.txt

recup_dir.425/f12364304.txt

recup_dir.425/f12364416.txt

recup_dir.425/f12363184.txt

recup_dir.425/f12364464.txt

recup_dir.425/f12363912.txt

recup_dir.457/f13682296.h

recup_dir.522/f15278408.imm

(........)

```

mais je lance ton test sur le backup disque pour voir ce que ça donne...

Sinon j'ai touvé cette explication sur le re-nommage 

 *Quote:*   

> 10.8.2. Identifying Files and Directories in the ReiserFS lost+found
> 
> To explore a filesystem's lost+found directory, you must first mount the filesystem, using the standard Linux mount command, which you must execute as the root user. When mounting ReiserFS filesystems, you must use the mount command's t reiserfs option to identify the filesystem as a ReiserFS filesystem and therefore mount it appropriately. Once the filesystem is mounted, cd to the lost+found directory at the root of that filesystem, which will be located in the directory where you mounted the filesystem. If this directory contains any files or directories, you're in luckthere's more data in your filesystem than just the standard files and directories it contains!
> 
> As with the lost+found directories used by other types of Linux filesystems, the entries in a ReiserFS lost+found directory are files and directories whose parent inodes or directories were damaged and discarded during the consistency check. You will have to do a bit of detective work to find out what these are, but two factors work in your favor:
> ...

 

Edit: Ben c'est pas vraiment mieux sur rebuild-tree de la partoche   :Crying or Very sad: 

```
lost+found # grep -R -l '/text/x-moz-place-container' *

grep: 10396938_20731749: Aucun fichier ou dossier de ce type

grep: 10396938_20731816: Aucun fichier ou dossier de ce type

grep: 10548601_10794249/CORE/libperl.so: Aucun fichier ou dossier de ce type

grep: 10548601_10794249/CORE/libperl.so.1: Aucun fichier ou dossier de ce type

grep: 10548601_10794249/CORE/libperl.so.1.5.8: Aucun fichier ou dossier de ce type

grep: 11877661_25931730/Linux2.6_x86_i686-pc-linux-gnu-gcc_glibc_PTH_OPT.OBJ/bin/nss-config: Aucun fichier ou dossier de ce type

grep: 11877661_25932003: Aucun fichier ou dossier de ce type

(...tourne_dans_le_vide...)

```

----------

## netfab

Tiens, une petite fonction bash qui permet d'analyser un fichier de bookmark backupé. La fonction calcule un timestamp pour une date donnée, et effectue une comparaison avec les timestamp contenus dans les fichiers analysés.

```

#!/bin/bash

timestamp_1=$(date -d '10 Feb 2011 00:01' +%s)

function searchTimestamp() {

    while read -d ',' line

    do

        if [ "${line:1:12}" = "lastModified" ]; then

            timestamp_2=${line:15:10}

            if [ $timestamp_2 -ge $timestamp_1 ]; then

                echo "timestamp ok ! fichier : $1"

                break

            fi

        fi

    done < $1

}

for x in *.json; do

    searchTimestamp $x

done

```

Par exemple, dans le répertoire suivant :

```

$ ls -l

total 124

-rw------- 1 netfab netfab 37206  9 févr. 11:28 bookmarks-2011-02-09.json

-rw------- 1 netfab netfab 37461 10 févr. 12:13 bookmarks-2011-02-10.json

-rw------- 1 netfab netfab 37461 11 févr. 15:30 bookmarks-2011-02-11.json

-rw-r--r-- 1 netfab netfab   436 12 févr. 19:13 moulinette.sh

```

 *Quote:*   

> 
> 
> $ bash moulinette.sh 
> 
> timestamp ok ! fichier : bookmarks-2011-02-10.json
> ...

 

Le script te sort les fichiers contenant un timestamp supérieur à celui du 10 Feb 2011 à 00:01. Combinée au grep de ton post précédent, la fonction pourrait à mon avis te faire le tri des patates : je pense que les fichiers txt doivent correspondre à différentes versions sur le système de fichier des fichiers  backup json. Il suffirait donc de modifier le script pour lancer la fonction sur chaque fichier txt sorti du grep pour voir s'il en resort quelque chose.

----------

## boozo

Merci beaucoup pour cette aide netfab j'ai essayé de tester ton script seulement photorec semble écraser les horodatages (et les droits ugo) à la récupération donc il ne trouve pas ou alors je m'y suis mal pris pour la récup initiale avec photorec  :Rolling Eyes: 

A force de grep sur différentes expressions j'ai pu retrouver des bribes de mes bookmarks sur 9 fichiers (*.f) mais c'est comment dire... légèrement en bouillie... pourtant je ne crois pas qu'il s'agissait d'un gros fichier en volume mais il semble pas mal fragmenté ou alors c'est la méthode utilisée pour la récup qui veux çà ?

/me continue à chercher

Edit: Je retente un coup de photorec avec plus d'options pour voir si c'est mieux et je dis

----------

## man in the hill

Salut

Utilise Tesdisk au lieu de photorec qui te permet de naviguer ds tes répertoires et de sauver ceux que tu veux sans le bordel de photorec.

----------

## boozo

Newnews: Je suis en pleine consultation du bordel depuis lors mais sur un échantillon de 175 fichiers (oué mais bon, c'est encore exploitable par un humain au départ j'en avait >130000   :Laughing:  ) et c'est très, mais alors très, très long   :Crying or Very sad: 

Tout est réellement mélangé sur le fs i.e. je trouve des bouts {d'email, de clés, de log de compil de portage, de binaire, ...} au sein même des fichiers qui matchent sur des bouts du json que je cherche alors faut tout passer en revue ligne à ligne mais au final j'arrive quand même à retouver des concordances en nettoyant (joie!).

C'est juste un "mégapuzzle"   :Laughing: 

Je continue voir si j'arrive à en finir un complêt réassemblé et je tente un import   ---> To be continued !

@man_in-the_hill: Je n'ai jamais utilisé Testdisk pour çà (juste pour des tables de partoches) mais je ne sais pas s'il se comporterait mieux au final... Mon plus gros problème là, c'est que je suis sur reiserfs alors niveau récup c'est pas la joie même avec ce type d'outils ; même le rebuild-tree n'a pas fait mieux.

D'ailleurs c'est le premier vrai reproche que je lui fait à ce fs mais je ne lui jette pas la pierre car /me seul en cause dans cette affaire et à plus d'un titre   :Rolling Eyes: 

----------

## man in the hill

 *boozo wrote:*   

> @man_in-the_hill: Je n'ai jamais utilisé Testdisk pour çà (juste pour des tables de partoches) mais je ne sais pas s'il se comporterait mieux au final...

 

Il faut combiner les deux pour avoir le maximum de chance ...

j'ai eu à utiliser testdisk et photorec et l'avantage de testdisk c'est que tu peux voir l'arborescence de système de fichier pour récupérer les répertoires que tu souhaites donc cibler plus facilement ta récup ...

----------

## boozo

SCORE : /me : 1 - photorec : 0

Avec de la patience, de la méthode, de la détermination - soit, de l'obstination viscérale et une overdose de café ces derniers jours - j'en suis venu à bout de tout ces petits bouts ! Le json de récup est en place depuis hier tard dans la nuit !   :Twisted Evil: 

Un grand "Merci" à Netfab pour m'avoir défriché la piste.

Allez tant pis si j'enfonce une porte ouverte : si vous aimez comme moi le reiser et avez la gachette facile sur les rm dans les oneliner -> pensez d'urgence à mettre i.e. un tar de backup dans vos cronjob !

Vous éviterez de devenir à 1/2 jobastre  :Laughing: 

(n.b. Vu l'étendue du bordel que j'avais alors que ma cible était minuscule, amha, si vous avez plus de 4Mo de fichiers à reconstruire : ne perdez pas vos belles années en vains travaux et filez directement au pub noyer votre chagrin. Vous vous ferez moins de mal)

----------

## kwenspc

 *boozo wrote:*   

> 
> 
> (n.b. Vu l'étendue du bordel que j'avais alors que ma cible était minuscule, amha, si vous avez plus de 4Mo de fichiers à reconstruire : ne perdez pas vos belles années en vains travaux et filez directement au pub noyer votre chagrin. Vous vous ferez moins de mal)

 

Oui mais maintenant tu peux aussi aller au pub pour fêter ça!

info 0 - pub 1. 

Santé! ^^

----------

