Rediriger un fichier vers /dev/null

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.

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.

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:

---

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

---

Bonjour,

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

Code:

---

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é...

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é.

Bonjour :coucou:

Citation:

---

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.

Citation:

---

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".

Citation:

---

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".

Citation:

---

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.

Citation:

---

Envoyé par N_BaH

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:

---

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?

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.

Citation:

---

Citation:

---

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.

Citation:

---

Envoyé par jack-ft

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.

Yop !

Citation:

---

Envoyé par Flodelarab

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 :mrgreen:
Quoique, on va voir que des fois c'est utile :

Citation:

---

Envoyé par disedorgue

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:

---

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. :mrgreen:

Citation:

---

Envoyé par kyzer

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, :ptdr:)

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.

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)

Citation:

---

s'il en ai capable

---

Du verbe "avoir capable" ?

:dehors:

:zoubi:

Pour les fichiers de type bloc ou de type caractère (cas de /dev/null), on passe la main au driver, et celui-ci considère (ou pas) qu'il doit déposer le contenu chez lui (qui est un "blackhole")
Le dit driver, renvoie au mv que c'est ok, et ça s'arrête là.

Bon, c'est dans les grosses mailles, l'explication.

Bonjour,
C'est avec désappointement que j'aperçois la teneur de certain, merci pour les réponses, celles valables données par des gens humbles ou de vrais experts. J'ai eu la chance de rencontrer d'immuables personnes mais aucun informaticien et un nombre incalculable de professeurs voir de correcteurs ou orthographieurs, d'autres pour éviter de se mouiller et de faire des fautes parlent en morse (3, 4 mots)... Je ne m'étais pas rendu compte que ceci étais une dictée. Je Pense que cela sera inutile pour ma part de répondre dans le futur car les réponses sont proches du néant et de valeur négative, exceptés celles valables données par des gens humbles ou de vrais experts, attendu qu'elles ne sont pas plus fines qu'un bloc de roche.
Cordialement.
ps: Flodelarab est un usurpateur car je n'ai jamais écrit : "s'il en ai capable" de tout mon post précédent mais s'il en est capable.

Citation:

---

Envoyé par 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.

---

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

Code:

---

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

Citation:

---

Envoyé par Flodelarab

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 :mrgreen:

Bonjour,
Merci.

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):

Citation:

---

Envoyé par kyzer

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:

Citation:

---

Envoyé par N_BaH

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é!

Citation:

---

Envoyé par kyzer

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:

Citation:

---

Envoyé par moi

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.

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.

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 :oops:
Et pour ceux qui ont essayés, je leur conseille de recréer leur device null :

Code:

---

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:

---

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

---

Citation:

---

Envoyé par disedorgue

Euh, chez moi, ça ne fonctionne pas le sudo mv fichier /dev/null,

---

:koi:

Citation:

---

Envoyé par disedorgue

Et pour ceux qui ont essayé, je leur conseille de recréer leur device null

---

Sinon, il est recréé en rebootant (tout au moins chez moi).

Bonjour,
En se penchant réellement sur la question et non sur des emplacements hasardeux de mes doigts lors de la frappe, disedorgue fait une remarque qui fait avancé les choses.
En effet lors de la commande sudo mv lefFichier /dev/null celle-ci écrase donc bien le fichier, la commande ls -l /dev/null montre bien que le fichier est au départ un fichier FIFO et qu'à l'écrasement
les permissions passe de crw-rw-rw- à celle du fichier déplacé.
Comme le dit disedorgue la commande $ sudo su - -c "cd /dev ; MAKEDEV std" recréera le device null ou un sudo reboot (plus long ...).
Donc dans ce cas que se passerait -il concrètement avec le /dev/null si il est donc écrasé ? Fonctionnerait-il toujours ? Sera-t-il capable de récupérer les flux ?
D'un œil non avisé je pense que le fonctionnement sera différent mais que cela n'empêchera pas forcément la redirection des flux et l'écrasement des derniers arrivés par les flux venant par la suite; cela sera comme écraser des flux par des autres sur un fichier régulier donc ?
Au redémarrage de la machine ou après la commande $ sudo su - -c "cd /dev ; MAKEDEV std" le /dev/nul écrasé par le ou un fichier régulier sera lui même ré-écraser par le /dev/null initiale (si ont peut dire...); se qui reviendra un peu au même je pense.
Si quelqu'un a une idée sur la question pourrait-il me donner son point de vue.
Merci cordialement.

Citation:

---

Envoyé par Jipété

:koi:


Sinon, il est recréé en rebootant (tout au moins chez moi).

---

Idem pour moi chez moi également il est recréé avec sudo reboot

Heureusement, qu'au reboot, il recrée les devices même si historiquement, ça n'a pas toujours été le cas.

Mais, j'imagine mal de devoir rebooter un serveur de production à cause d'une mauvaise manipulation de ce genre :aie:

Alors, le fcihier /dev/null n'est pas un FIFO mais un fichier device de type caractère.

Et le fait que celui-ci soit transformé en fichier normal peut devenir très impactant pour ton système:
-Problème de droit
-Disque dur qui se sature de façon non visible (et oui, on peut continuer à remplir un fichier qui a été supprimé)

Voici un exemple que l'on emploi de temps en temps pour par exemple modifier des fichiers sans passer explicitement par un fichier tampon:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

$ ls -ai 7036874418195687 . 89790517570844964 .. 17169973579771568 bob $ cat bob 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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 $ exec 3<bob $ rm bob $ ls -ai 7036874418195687 . 89790517570844964 .. $ cat <&3 >bob $ ls -ai 7036874418195687 . 89790517570844964 .. 6755399441122155 bob $ cat bob 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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

---

Code:

---

1 2 3 4 5 6

$ exec 3<bob $ rm bob $ ls -ai 7036874418195687 . 89790517570844964 .. $ cat <&3 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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

---

Comme tu peux le voir dans les 2 exemples, on efface le fichier avant d'exploiter les données du dit fichier.
Le premier exemple, est juste là pour montrer que dans ce cas, on change bien l'inode du fichier que l'on modifie.

Bonjour,
Merci infiniment pour toutes ces informations et pour le temps passé afin de m'apporter des réponses qui m'ont grandement servi et m'ont été d'une grande aide.
Merci également pour votre réactivité à tous et pour le soutien, réellement important, que vous apportez (bénévolement) aux débutants ou à tous ceux qui se posent des questions.
Mention spécial pour disedorgue, jack-ft, papajoker, N_BaH.
Mention pour JipétéTrès cordialement.