D’accord avec syam, ça n’a aucun intérêt pour effacer des fichiers de façon sûre.
Ben non, même problème que pour shred avec les systèmes de fichiers “modernes” : rien ne garantit que les zéros vont être écrits sur l’ancien emplacement du fichier.[/quote]
??? Je rêves ou quoi ? ils vont êtres écrits sur la Lune mes zéros ? ou dans mon fichier ? à mon avis ils vont être écrits dans mon fichier et pas sur la Lune !!!
La notion de fichier est une abstration du système de fichiers. Au final, le contenu d’un fichier est écrit dans des blocs sur le disque, qui ne sont pas accessibles directement à l’utilisateur mais seulement par l’intermiédiaire du système de fichiers, qui gère comme ça lui chante la correspondance entre les blocs et les fichiers. Lorsqu’on remplace le contenu, rien ne garantit que les nouvelles données vont être écrites dans les mêmes blocs et donc que les données précédentes vont être écrasées. Le fait qu’elles ne soit plus accessibles en lisant le fichier ne signifie pas qu’elles ont disparu du disque.
On peut même envisager un système de fichiers que décide que quand on écrit une longue suite de zéros dans un fichier, il n’y a pas besoin d’allouer des blocs sur le disque : il suffit de dire qu’il y a n zéros. Je suis sûr que ça existe déjà.
D’ailleurs il m’est arrivé d’avoir à effacer des fichiers contenant des infos perso, pour être sûr d’y parvenir, j’ai dans un premier temps “effacé” tous les fichiers perso avec un classique rm, puis j’ai entré cette commande :
puis j’ai attendu que Gros_fichier remplisse l’espace disponible, autant dire que le disque était remplis à 100 % , puis j’ai interrompu ma commande dd avec un simple Ctrl-C , puis
Tu crois sérieusement que sur ce coup là je n’ai pas tout effacé ?
Moui … c’est un peu flou, tout ça, toujours est-il que dans mon post précédent je donne une méthode sûre pour effacer définitivement des fichiers, c’est du lourd, certes, mais c’est sûr que ça marche !
La page de manuel de shred est assez édifiante, je trouve.
A condition de l’exécuter en tant que root ou sur un système de fichiers qui n’a pas d’espace réservé (5% par défaut sur ext2/3/4).
Et à condition qu’entre la suppression et l’écrasement, des blocs appartenant aux fichiers effacés n’aient pas été préalloués pour de nouveaux fichiers, comme le permet notamment ext4.
La page de manuel de shred est assez édifiante, je trouve.[/quote]
Je reconnais ne l’avoir lu que très-très rapidement ! C’est sûr que j’ai beaucoup à apprendre là dessus ( s’il n’y avait que ça ! ) Et en + ça m’interresse …
[quote=“PascalHambourg”]
A condition de l’exécuter en tant que root ou sur un système de fichiers qui n’a pas d’espace réservé (5% par défaut sur ext2/3/4).[/quote]
Je ne me souviens plus si j’ai exécuté cette commande en tant que root ( je penses que oui )
L’espace réservé n’est pas destiné a recueillir des fichiers qu’on tenterai d’éliminer, il est destiné à la survie du système de fichier lui même
Encore pire, ça dépend également du disque.
Bref, pour un SSD il est quasiment impossible de s’assurer que des données ont été effacées. Et dans les deux cas (SSD et disques à plateau) le seul moyen d’être 100% sûr est de détruire physiquement le disque (pilonnage). 
Et quand entre Gros_fichier ( 
) et le reste de la partition, il ne reste rien d’autre qu’un espace de survie pour le système de fichier en question ( quel qu’il soit) à votre avis il reste encore quelque chose des fichiers supprimés ?
Bon, si vous dites oui, je sens que je vais me faire moine ! et les moines hein ! y zont la belle vie 
Ben relis ce que j’ai marqué dans mon message précédent, et tu verras que ça peut arriver même sur les disques à plateau (les SSD j’en parle même pas). 
Non. La notion d’espace réservé ne définit pas un emplacement physique réservé, mais simplement une logique de fonctionnement.
Quand un utilisateur veut ajouter des données dans un fichier, nécessitant d’allouer des blocs :
La conséquence est qu’un utilisateur non root ne pourra pas écraser toutes les données des fichiers supprimés en créant un gros fichier remplissant tout le disque, parce qu’il ne peut pas créer un fichier remplissant tout le disque. Et dans l’espace où il ne pourra pas écrire, il peut très bien rester des données des fichiers supprimés.
MEB ? Mec en bleu ?
Ok, ça peut arriver que des données se retrouvent dans le “formol” de block défectueux, mais franchement la probabilité pour qu’un fichier entier s’y retrouve n’est pas nulle mais presque, et même dans ce cas ça reviendrait à ne chercher des fichiers effacé que dans ces blocks en questions, ce qui simplifierai la tâche quelque part, en tout c’est bien intéressant ce que vous dites ! 
Oups le B (comme Balayage) était probablement en trop, c’est sorti tout seul. Je pensais à ça.
Cela dit le Mec En Bleu est une excellente interprétation aussi !
J’avais bien compris ça ! Je pense que j’ai eu assez de “jugeote” pour le faire en root … En fait je n’ai jamais vraiment cherché à être absolument sûr que toutes ces données étaient bien effacées (au fond je m’en fiche, je jouais à 24h chrono dans mon coin !) je le pensais pourtant. On en apprend tous les jours … c’est ça qui est bien
Bah ! je suis sûr ( ) qu’il y a un autre moyen que celui évoqué par Syam … mais j’ai pas le temps de chercher ! hummm , voyons ? quand je serais moine j’aurais le temps !
Oups le B (comme Balayage) était probablement en trop, c’est sorti tout seul. Je pensais à ça.
Cela dit le Mec En Bleu est une excellente interprétation aussi ! [/quote]
J’adore ! la science, c’est beau et con à la fois !
Sur ce je vous laisse sur ce topic, les pompiers m’appellent !
Euh… Sauf erreur grossière de ma part l’instrument sur la photo ne ressemble pas à un microscope électronique mais à un banal microscope optique binoculaire. Il y a d’autres informations dans ce “reportage” qui me laissent dubitatif. La plus “grosse” :
De quoi surprendre quiconque a déjà vu un plateau (c’est épais) et une tête (c’est tout fin) de disque dur !
Je n’ai donné ce lien que parce que c’était le premier en réponse à la requête “<nom de société> microscope”, pour tout t’avouer j’y ai à peine jeté un coup d’œil. Mea maxima culpa. 
Mais je connais la société en question et je sais qu’ils utilisent des microscopes électroniques pour la récupération de données (on était voisins à une époque).
Salut,
Je le savais 
j’ai retrouvé …
Grosso modo oui. En vrai pour comprendre ce qu’il se passe il faut savoir ce qu’est un fichier.
Un fichier c’est un volume de données quelconque et un ensemble de méta-données (droits, date, etc). Le système gère différemment les deux parties.
La première partie est stockée d’une manière différentes en fonction du système de fichier, on s’en fout un peu. Ce qui est intéressant c’est les métadonnées. Elles sont stockée différemment car elles sont utilisées par le système. Elles sont regroupée dans une inode.
Quand on prend un fichier, /etc/passwd par exemple, le système d’exploitation l’associe à une inode. Celle-ci est accessible permet ensuite de retrouver l’ensemble du fichier. La commande ln, quand elle n’est pas utilisée avec l’option -s, permet de créer un nouveau chemin associer à ce même inode. Ainsi Quand on modifie l’un des deux fichiers, les deux sont modifiés.
$ cat > /tmp/coucou
salut c'est moi
$ ln /tmp/coucou /tmp/hello
$ less -FSRX /tmp/hello
salut c'est moi
$ ls -l /tmp
-rw-r--r-- 2 michel michel 16 27 oct. 23:02 coucou
-rw-r--r-- 2 michel michel 16 27 oct. 23:02 hello
$ cat >> /tmp/hello
non je rigole
$ cat /tmp/coucou
salut c'est moi
non je rigole
La seconde colonne de ls -l donne le nombre de liens qui pointe vers cet inode.
L’opération de suppression d’un fichier se fait par l’appel système unlink() qui se content de supprimer un lien. Ainsi pour mon fichier /tmp/hello :
$ rm /tmp/hello
$ ls /tmp
coucou
$ cat /tmp/coucou
salut c'est moi
non je rigole
Quand le nombre de liens arrive à 0, le système va supprimer l’inode (et encore je suis pas sûr), mais il ne touchera pas au reste du fichier. C’est mieux pour les performances.
C’est ce qui a posé des problèmes avec les SSD. Comme ils ont une couche logicielle à eux et que le système d’exploitation en luis disait jamais quel blocs était libéré, le disque se remplissait. La fonction trim a permis de corriger le tire et la fonction bigtrim de l’améliorer encore.
Au passage quand tu fais un mv et que tu reste dans la même partition la commande se contente de créer un nouveau lien et de supprimer l’ancien (tu a l’impression de déplacer 200Gio en une fraction de seconde).
Si tu veux vraiment supprimer un fichier je te conseil d’aller voir du coté de shred (le man est très clair).[/quote]
recuperation-fichier-supprime-par-erreur-t35928.html#p362619
En fait j’ai fait quelques recherches depuis l’autre jour sur ce sujet, et on peut sans problème monter un EXT3 en EXT2, il n’y a donc plus de
problèmes liés à la journalisation, reste tout de même les pb des SSD évoqués par Syam et la nécessité d’être root évoqué par
PascalHambourg pour la manip “Gros_fichier” que je suggérais ( avant d’entrer dans les ordres … )
Merci Loreleil pour le wipe que je ne connaissais pas
L’ultime solution étant le chiffrage des données avant leur écriture sur un disque ( surtout SSD si j’ai bien compris ) parce que
dans ce cas qu’est-ce que ça peut bien faire que les fichiers soient récupérables ? )
voici la manip que j’ai testé aujourd’hui pour monter mon home en EXT2 et accéder à mom rep perso chiffré avec eCryptfs, ça marche,
mais si les données sont chiffrées ce n’est qu’une perte de temps de faire tout ça, mais ça m’intéressait d’essayer ça, je vous donne cette
manip si ça vous intéresse :
Bonne journée
[code]### (re)-démarrer l’ordi
mount|grep home
/dev/sda7 on /home type ext3 (noatime,rw)
umount /home
mount|grep home
mount -t ext2 /dev/sda7 /home
EXT2-fs warning (device sda7): ext2_fill_super: mounting ext3 filesystem as ext2
mount|grep home
/dev/sda7 on /home type ext2 (rw)
shred , wipe , dd + /bin/rm
mount | grep home
/dev/sda7 on /home type ext2 (rw)
/home/.ecryptfs/toto/.Private on /home/toto type ecryptfs (rw,nosuid,nodev,noatime,ecryptfs_sig=,ecryptfs_cipher=,ecryptfs_key_bytes=**,ecryptfs_fnek_sig=***,ecryptfs_unlink_sigs,user=toto-deb)
sync (pas obligatoire)
reboot
[/code]
Et si on utilisait une telle méthode:
disque dur 1: système principale debian
disque dur 2: vide non utiliser
1 étape: utilisation du système sur le disque dur 1, utilisation normal, donc faire des suppressions normal avec rm ect.
2 étape: après X temps ou X raison, installation du système sur le disque 2, démarrer avec, monter le disque dur 1, copie nos données du disque dur 1 au système du disque dur 2.
3 étape: utiliser des méthodes comme dd sur le disque dur 1.
4 étape: après X temps ou X raison, installation du système sur le disque 1, démarrer avec, monter le disque dur 2, copie nos données du disque dur 2 au système du disque dur 1.
5 étape: utiliser des méthodes comme dd sur le disque dur 2.
…
…
.
Cet méthode peut-être efficace, mais juste une question qui me pertube qui change le résultat:
Lors de la copie des données du disque dur 1 au disque dur 2, est-ce qu’on copie juste les données normal non éffacé ou on copie les données normal non éffacé + les données dite éffacé mais pas réel ?
Normalement oui si on fait une copie des fichiers existants, seul leur contenu sera copié.
En revanche si on copie le contenu brut de la partition, on copie tout, y compris les restes des fichiers supprimés.