Discussion :

[kyzer]

Bonjour à tous,
Je suis nouveau dans le monde de la programmation et des systèmes Unix en l'occurrence sous linux Ubuntu 14.04 LTS.
Dans mon apprentissage je souhaite réellement comprendre le fonctionnement de cet OS.
Ma question est basé sur les redirections de flux vers le /dev/null (appelé the black hole).
Je souhaiterais savoir si rediriger un fichier vers /dev/null rend la restauration de ce dernier impossible même à partir du disque dur ?
D'après mes recherche sur le net j'ai pu lire que lorsque qu'un fichier est supprimé c'est le chemin du pointeur vers ce fichier qui est cassé mais
est toujours récupérable car toujours présent sur le disque.
Est ce que le faite de rediriger un fichier vers /dev/null envoie également le pointeur du fichier dans le "black hole" et rend sa récupération impossible même à partir du disque dur?
Malgré toutes mes recherche et tests je n'ai pu avoir une réelle réponse concrète.
Merci à tous.

[N_BaH]

Bonjour,

il n'est pas possible de rediriger un fichier vers /dev/null.
on ne peut y rediriger qu'un flux, émanant d'une commande, mais le fichier ne sera pas modifier.

[papajoker]

Bonjour,

tu as la commande shred pour supprimer définitivement un fichier sans aucune possibilité de récupération
mais en faisant une redirection vers le fichier cela peut-être suffisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
echo >lefichier && rm lefichier
head -c 2M /dev/zero >lefichier && rm lefichier
head -c $(stat -c %s lefichier) /dev/zero>lefichier && rm lefichier

[disedorgue]

Bonjour,

Ok pour shred, mais les autres methodes ne garantissent pas l'effacement des données du disque dur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ dd if=/dev/zero of=/dev/stdout count=100 >bob
100+0*enregistrements lus
100+0*enregistrements écrits
51200*octets (51 kB) copiés, 0,00104507*s, 49,0 MB/s
$ filefrag -skv bob
Filesystem type is: ef53
File size of bob is 51200 (52 blocks of 1024 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      51:   15223028..  15223079:     52:             last,eof
bob: 1 extent found
$ dd if=/dev/zero of=/dev/stdout count=100 >bob
100+0*enregistrements lus
100+0*enregistrements écrits
51200*octets (51 kB) copiés, 0,000874106*s, 58,6 MB/s
$ filefrag -skv bob
Filesystem type is: ef53
File size of bob is 51200 (52 blocks of 1024 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      51:   15237312..  15237363:     52:             last,eof
bob: 1 extent found

Comme on peut le voir, les physical offset sont différents et en plus ici, on est dans le cas le plus simple car tous les blocks se suivent, on a encore moins de chance quand le fichier est fragmenté...

[kyzer]

Bonjour,
Merci à tous pour votre réactivité et vos réponses.
Pour réagir à la réponse de N_BaH sur laquelle je suis entièrement d'accord il est vrai que seul les flux doivent être redirigés vers /dev/null mais malgré tout la bidouille est possible la commande
mv Bureau/leFichier /dev/null sera exécutée dans le shell.
La remarque de papajoker est une très bonne remarque selon moi car je ne connaissais pas la commande shread qui semble être une très bonne commande néanmoins, comme le fait remarquer disedorgue, il semblerais
que le code source n'affecte pas réellement le disque dur, ce que je pense également car le fichier n'est qu'en gros qu'écrasé sur lui même.
La vision de disedorgue est à la fois précise, pointue, et pertinente. Les commandes employées parlent d'eux même et les physical_offsets indique bien un déplacement en mémoire équivalent à la taille du fichier si je ne me trompe pas et est donc effectivement vrai que la fragmentation rendrais la récupération d'un fichier impossible.
Vos réponses, codes sources et remarques m'ont été très bénéfiques un grand merci à vous tous et encore merci pour votre réactivité.

[Flodelarab]

Bonjour

la commande
mv Bureau/leFichier /dev/null sera exécutée dans le shell.

Dans ma console, il demande si je veux écraser un fichier par l'autre. Il ne veut donc pas supprimer le fichier ... mais le déplacer. Et je ne veux pas supprimer /dev/null.

La remarque de papajoker est une très bonne remarque selon moi car je ne connaissais pas la commande shread

Et pour cause. Ce n'est pas "shread" mais "shred".

comme le fait remarquer disedorgue, il semblerais que le code source n'affecte pas réellement le disque dur,

Disedorgue ne dit pas ça. Il dit même exactement le contraire: "Ok pour shred".

il semblerais que le code source n'affecte pas réellement le disque dur

Sauf que si tu avais plongé, ne serait-ce qu'une seconde, dans le man shred, tu aurais vu que la commande écrit et réécrit (3 fois par défaut) dans le fichier pour que l'information contenue ne puisse pas être retrouvée comme le font les professionnels de la sécurité. (ou réécrit 5 fois selon la parano). Ce qui est le but d'une commande plus lourde qu'un simple rm.

Mon cher ami, vous avez des problèmes de compréhension.

[Jipété]

Yop !

Ce n'est même pas un écrasement de fichier.

Stricto sensu moi je dirais que oui, quand même : tu écrases les données du fichier avec d'autres données, mais bon, je pinaille
Quoique, on va voir que des fois c'est utile :

Comme on peut le voir, les physical offset sont différents et en plus ici, on est dans le cas le plus simple car tous les blocks se suivent, on a encore moins de chance quand le fichier est fragmenté...

J'ai refait tes manips (c'est quoi ton système ? Tes blocks font 1024 les miens 4096, et je n'ai pas l'option -k de filefrag...), mais je les ai faites 3 fois à la suite (un truc me chiffonnait) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# dd if=/dev/zero of=/dev/stdout count=100 > bidon 
100+0 enregistrements lus
100+0 enregistrements écrits
51200 octets (51 kB) copiés, 0,000425403 s, 120 MB/s
# filefrag -sv bidon 
Filesystem type is: ef53
File size of bidon is 51200 (13 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  3319020              13 eof
bidon: 1 extent found
# ls -li bidon 
845426 -rw-r--r-- 1 xxxx xxxx 51200 déc.  16 13:14 bidon
 
# dd if=/dev/zero of=/dev/stdout count=100 > bidon 
100+0 enregistrements lus
100+0 enregistrements écrits
51200 octets (51 kB) copiés, 0,000434273 s, 118 MB/s
# filefrag -sv bidon 
Filesystem type is: ef53
File size of bidon is 51200 (13 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  3319033              13 eof
bidon: 1 extent found
# ls -li bidon 
845426 -rw-r--r-- 1 xxxx xxxx 51200 déc.  16 13:14 bidon
 
# dd if=/dev/zero of=/dev/stdout count=100 > bidon 
100+0 enregistrements lus
100+0 enregistrements écrits
51200 octets (51 kB) copiés, 0,000419327 s, 122 MB/s
# filefrag -sv bidon 
Filesystem type is: ef53
File size of bidon is 51200 (13 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  3319020              13 eof
bidon: 1 extent found
# ls -li bidon 
845426 -rw-r--r-- 1 xxxx xxxx 51200 déc.  16 13:15 bidon

Et là on se rend compte que l'offset a été modifié, mais pas l'inode : pour moi, le fichier a été créé et l'OS l'a mis à l'offset 3319020, puis il a été écrasé par la deuxième commande, qui se décompose en deux temps : 1, on écrit les nouvelles données à l'offset 3319033 et 2, on supprime l'ancien, et enfin, troisième manip l'offset 3319020 étant maintenant libre le fichier est "autorisé" à réoccuper cet emplacement.
Enfin, il me semble.

Pour répondre à Flodelarab qui semble avoir la science infuse : la différence entre "shread" et "shred" s'appelle une faute de frappe Monsieur Aristote.(j'avais bien précisé que j'étais débutant dans le début de ma discussion).

Hé ho, on n'est pas là pour deviner à travers les fautes de frappe ce que les autres ont voulu dire, hein. Alors un peu de respect pour ceux qui essayent de comprendre ce que tu racontes d'une manière confuse.
Et moi aussi je suis débutant (ça fait juste 45 ans que je débute, )

[disedorgue]

Mon OS, c'est Lubuntu (perso, chez moi, il y a une autre option qui ne fonctionne pas mais je ne sais plus laquelle et là, je ne peux pas vérifier).
Sinon, tu peux refaire ton test mais sans l'option '-s' , comme ça tu auras la chance de voir que tu ne synchronise pas, cela reste dans le cache et donc n'alloue pas de bloc sur le disque et qu'une fois que la synchro est faite, les blocs sont alloués (bon, le sync dépend aussi de la taille de ton cache)

Et que rien que par se phénomène, tu peux réutiliser du premier coup les mêmes blocs...

En fait, c'est assez hasardeux, car cela va complètement dépendre de l'activité de ton disque induit par d'autres processus au moment du test.

[kyzer]

Bonjour,
Jipété c'est bien de militer pour l'orthographe surtout sur des noms de commandes qui ne sont pas forcément en français.
Je n'avais pas anticipé que "shread" à la place de "shred" aurait suscité une telle confusion dans les esprits de professionnels qui pratiquent depuis plus de 40 ans surtout lorsque le nom de la commande est écrite dans le champs de celui qui l'indique (faire le lien ou rapprochement peut s'avérer complexe selon certain).
Je peux lire que certaines personnes ne sont pas là pour deviner ce qu'on explique de manière confuse je peux comprendre de manière indirecte par ces personnes que ce forum n'est pas destiné aux débutants ayant des questions confuses et dans ce cas, je peux donc également comprendre que ces personnes qui pratiquent depuis plus de 40 ans n'ont surement jamais été confuses dans leurs questions surtout à leurs débuts.
En tout de long ou de large ces soit disant personnes n'apportent pas plus de réponse sur la question car c'est surement plus simple de se pencher sur une faute de frappe.
Maintenant que Jipété, s'il en est capable, m'explique ce qu'il se passe lors de la suppression d'un fichier et s'il est possible de le restaurer à partir du disque dur ou autres lorsque on exécute la commande : sudo mv leFichier.txt /dev/null. Une explication non confuse ne serait pas de refus et la réponse: " la commande : sudo mv leFichier.txt /dev/null est impossible " ne sera pas considérée comme recevable car sur mon OS cela fonctionne parfaitement.
Merci cordialement .
ps: désolé pour les fautes d'orthographe ou les fautes de frappe... (mon ps risque d'être incompréhensible)

[jack-ft]

il n'est pas possible de rediriger un fichier vers /dev/null.
on ne peut y rediriger qu'un flux, émanant d'une commande, mais le fichier ne sera pas modifier.

Euh... chez moi, ça semble bien modifier le fichier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ ls -li coucou
12108371 -rw-rw-r--  1 jack  staff  7 14 déc 17:06 coucou
 
$ cat /dev/null >| coucou
 
$ ls -li coucou
12108371 -rw-rw-r--  1 jack  staff  0 14 déc 17:06 coucou

Apparemment, c'est bien le même inode, non?

[kyzer]

Bonjour,

Pour répondre à Flodelarab qui semble avoir la science infuse : la différence entre "shread" et "shred" s'appelle une faute de frappe Monsieur Aristote.(j'avais bien précisé que j'étais débutant dans le début de ma discussion).
Selon toi si j'avais plongé dans le man "shred" ...ect... je n'imagine bien que tu n'étais pas à coté de moi lors de mes recherches , pour ta gouverne Mr Aristote j'ai bien plongé dans le man "shred" avant de répondre.
Mr Aristote, d'où émane la science et la lumière, le problème de compréhension ne peut venir que de votre perception des choses car elle est erronée . En effet lorsque je commente la réponse de disedorgue
et que j'affirme que le disque dur n'est pas affecté il fallait évidemment comprendre que je voulais dire que le fichier n'est pas supprimé du disque dur, vu que je confirme un déplacement en mémoire donc une modification sur le disque et vu que le sujet était plus précisément porté sur la récupération d'un fichier, mais je peut comprendre que lorsque la science et la connaissance fait partie de notre chair un peu facilement penser qu'ont a forcément raison sur tout ...
Je ne sais pas sur quelle version de linux Monsieur Flodelarab est mais lorsque j' exécute la commande : sudo mv Bureau/leFichier /dev/null le fichier sera bien déplacé dans /dev/null, mais /dev/null ne sera aucunement écrasé par le fichier envoyé car /dev/null est un fichier spécial . Il te suffisait juste d'essayer d'envoyer un fichier dans /dev/null et de lire le contenu avec : tail --follow /dev/null tu aurais vu que ton /dev/null est toujours fonctionnel la différence, il, me semble, sera qu'a l'envoi du fichier dans /dev/null le fichier que tu sera entrain de lire aura changé, il faudrait donc relancer la commande tail --follow /dev/null afin de relire le bon fichier; en redirigeant un flux au lieu d'un fichier tu verras bien que le flux a bien été redirigé et que ton fichier /dev/null est toujours un fichier spécial et non le "regular file" que tu envoyé.
Dernier exemple tu n'as qu'a créer 2 fichiers un sur Bureau un fichier a avec écrit "a" a l'intérieur et un second fichier dans ton home fichier b avec ecrit "b" à l'intérieur et tape la commande :
mv Bureau/a /home/b et dit moi si ton fichier b a été supprimé ?... Non il sera bien présent avec le flux du fichier a dans le fichier b et le fichier a aura disparu...
Autrement dit ou vu autrement c'est comme si on avait redirigé le flux en supprimant le fichier a.
Donc par définition si tu fais sudo mv Bureau/leFichier /dev/null dit moi si ton fichier /dev/null aura disparu Monsieur Aristote .
Je remercie jack-ft de faire des vrais tests et d'essayer réellement les commandes car pour lui tout comme moi on a le même résultat en envoyant un fichier dans /dev/null le flux est bien renvoyé lorsque on exécute la commande :
cat /dev/null >| Bureau/NewFile le contenu du fichier envoyer dans /dev/null est bien récupéré sur Bureau/newFile merci jack-ft conforté ma thèse et est 100% d'accord avec toi et m'apporte bien plus d'informations de qualité que Aristote aurait pu faire.
Merci à tous Cordialement.

[Flodelarab]

il n'est pas possible de rediriger un fichier vers /dev/null.

chez moi, ça semble bien modifier le fichier:

Tu ne rediriges pas un fichier vers /dev/null mais tu rediriges /dev/null vers un fichier.

Apparemment, c'est bien le même inode, non?

Tu remplaces un contenu par un autre contenu. Pourquoi voudrais-tu qu'il change d'inode ?
Ce n'est même pas un écrasement de fichier.

[Jipété]

Bonjour,

il n'est pas possible de rediriger un fichier vers /dev/null.
on ne peut y rediriger qu'un flux, émanant d'une commande, mais le fichier ne sera pas modifier.

Ben, écoute, on dirait qu'il a raison le jeune : je viens d'essayer ça dans une machine virtuelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ touch bidon
$ echo 123456789 > bidon
$ ls -Al
$ -rw-r--r-- 1 xxxx xxxx 10 déc.  16 18:11 bidon
$ mv bidon /dev/null
$ ls -Al
$

Et si je refais la même manip avec l'option -i (pour un mv avec confirmation interactive), je récupère comme

Dans ma console, il demande si je veux écraser un fichier par l'autre. Il ne veut donc pas supprimer le fichier ... mais le déplacer. Et je ne veux pas supprimer /dev/null.

À ce stade j'ai considéré que c'était une traduction mal appropriée et qui faisait peur, mais comme j'étais en MV j'ai dit "y" et le fichier a disparu, et sans que ça me casse mon /dev/null

[kyzer]

Bonjour,
Merci.

[jack-ft]

En fait, il me semble qu'il y a eu une confusion au départ.
L'intitulé de la question est "Rediriger un fichier vers /dev/null".
Et le premier post indique (en gras, par moi):

Je suis nouveau dans le monde de la programmation et des systèmes Unix en l'occurrence sous linux Ubuntu 14.04 LTS.
Dans mon apprentissage je souhaite réellement comprendre le fonctionnement de cet OS.
Ma question est basé sur les redirections de flux vers le /dev/null (appelé the black hole).
Je souhaiterais savoir si rediriger un fichier vers /dev/null rend la restauration de ce dernier impossible même à partir du disque dur ?
D'après mes recherche sur le net j'ai pu lire que lorsque qu'un fichier est supprimé c'est le chemin du pointeur vers ce fichier qui est cassé mais
est toujours récupérable car toujours présent sur le disque.
Est ce que le faite de rediriger un fichier vers /dev/null envoie également le pointeur du fichier dans le "black hole" et rend sa récupération impossible même à partir du disque dur?
Malgré toutes mes recherche et tests je n'ai pu avoir une réelle réponse concrète.
Merci à tous.

Or, le concept de redirection de flux est (relativement!) clair pout tout non-débutant.

Et la réponse de N_BaH est sans appel:

il n'est pas possible de rediriger un fichier vers /dev/null.
on ne peut y rediriger qu'un flux, émanant d'une commande, mais le fichier ne sera pas modifier.

Ben oui! Parce qu'on sait bien ce qu'est la redirection de flux.

Ensuite l'utilisateur parle de la commande "mv" qui, pour tout non-débutant, n'a rien à voir avec la redirection de flux.

J'ai ajouté un peu de ponctuation pour améliorer la lisibilité!

Pour réagir à la réponse de N_BaH, sur laquelle je suis entièrement d'accord, il est vrai que seul les flux doivent être redirigés vers /dev/null, mais malgré tout la bidouille est possible.
la commande mv Bureau/leFichier /dev/null sera exécutée dans le shell.

Après, ça part un peu en cacahuète... selon les susceptibilités des divers interlocuteurs.

Mais, du coup, il me semble que la question est quelque chose comme:

Après avoir exécuté, dans un shell, la commande mv leFichier /dev/null, est-il possible de restaurer le fichier?

Il faut savoir qu'il y a plusieurs types de restauration:
* une méthode en allant regarder les bits dans les secteurs du disque dur
si on n'a pas écrit sur l'ancien emplacement du fichier, il est possible de le restaurer
si on a écrit sur l'ancien emplacement du fichier, c'est plus difficile et même impossible avec les moyens propres au disque dur.

* une méthode en allant regarder à un niveau plus fin que les bits dans les secteurs du disque dur
Certains diront qu'un bit est un bit et qu'il est à 0 ou à 1.
En théorie oui, mais en pratique non!
Quand on écrit un 0 ou un 1 sur un disque dur, on magnétise une très petite surface, mais qui ne contient pas qu'un seul atome!
Si on écrit par-dessus, on va changer la magnétisation d'une surface relativement semblable (ça dépend de la précision des têtes d'écriture du disque).
C'est comme mettre un coup de tampon sur un autre coup de tampon.
Si on n'est pas exactement au même endroit (ce qui est toujours plus ou moins le cas), le 2ème coup efface la partie commune aux 2 coups et laisse intacte une petite partie du bit initial.
Évidemment, la lecture du disque avec sa propre tête de lecture retrouvera bien la nouvelle valeur.
Mais il existe des spécialistes (avec des moyens financiers assez importants) qui arrivent à "scanner" la surface du disque à un niveau plus fin que ce que sait faire la tête de lecture et ils peuvent arriver à récupérer un fichier bien que ses bits aient été écrasés.

[kyzer]

Bonjour,
Je pense que jack-ft selon moi a très bien résumé l'ensemble et le pourquoi du comment de ce qui à la base était une question à titre d'information en quête d'apprentissage afin d'évoluer.
Due à mon niveau qui n'est indéniablement pas au même rang que celui d'expert ou de professionnel il était logique que les ambiguïtés et fautes de langage soient de mise mais je pense que la question était suffisamment décrite dans le ou les post(s) étant donné que plusieurs personnes en avaient compris le sens précis.
Pour revenir au sujet la réponse de jack-ft est plus que satisfaisante et dépasse bien mes espérances je te remercie grandement.
Cordialement.

[disedorgue]

Euh, chez moi, ça ne fonctionne pas le sudo mv fichier /dev/null, donc le driver /dev/null ne supporte bien que des flux et pas des fichiers et donc se que j'expliquais dans mon précédent post est du n'importe quoi
Et pour ceux qui ont essayés, je leur conseille de recréer leur device null :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ echo toto >titi
$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 déc.  16 20:23 /dev/null
$ sudo mv titi /dev/null 
$ ls -l /dev/null
-rw-rw-r-- 1 disedorgue disedorgue 5 déc.  16 20:23 /dev/null

La commande pour recréer votre device null

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ sudo su - -c "cd /dev ; MAKEDEV std"
$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 déc.  16 20:25 /dev/null