Je peux lire dans / dev / null; comment le réparer?


80

J'ai lu l'article de Wikipedia/dev/null et je jouais en déplaçant des fichiers vers /dev/null.

Pour cela j'ai créé un test_fileet y ai mis du contenu:

$ touch test_file
$ echo "This is written by Aditya" > test_file
$ cat test_file
This is written by Aditya

Ensuite, j'ai essayé de déplacer le fichier vers /dev/null:

$ mv test_file /dev/null
mv: inter-device move failed: ‘test_file’ to ‘/dev/null’; unable to remove target: Permission denied

Depuis, cela m'a donné une Permission deniederreur; Je suis allé de l'avant et utilisé sudocomme je le fais normalement chaque fois que je rencontre une Permission deniederreur.

$ sudo mv test_file /dev/null

La commande a réussi et test_filen'est plus présente dans le répertoire.

Cependant, l'article de Wikipedia dit qu'il n'est pas possible de récupérer quoi que ce soit déplacé /dev/nullet donne un EOFprocessus à tout processus qui essaie de le lire. Mais je peux lire /dev/null:

$ cat /dev/null
This is written by Aditya

Qu'est-ce que j'ai mal fait et comment puis-je /dev/nullrevenir à la normale? Et pourquoi ai-je rencontré une Permission deniederreur en premier lieu?

Réponses:


147

/dev/nullest un fichier. Un fichier spécial. Un fichier de périphérique tel que / dev / sda ou / dev / tty qui communique avec un élément matériel de votre système.

La seule différence avec, /dev/nullc'est qu'aucun matériel n'y est lié. Toutes les données que vous lui envoyez sont éliminées en silence. Comme la commande suivante:

echo "Hello World" > /dev/null

ce qui n'imprimera rien sur votre terminal car vous envoyez la sortie de echoto null, au vide, un trou noir ainsi.

Mais quand vous avez fait, mv test_file /dev/nullvous avez remplacé le fichier spécial /dev/nullpar un fichier texte normal, en conservant une copie du contenu de votre fichier test_file. En d'autres termes, vous avez perdu votre /dev/null.

Maintenant, ce que vous devez faire est (pour le reconstruire):

sudo rm /dev/null
sudo mknod -m 0666 /dev/null c 1 3

Vous devriez le reconstruire car beaucoup de scripts envoient la sortie à /dev/null. Si ce /dev/nulln’est plus un trou noir mais un fichier texte ordinaire, il peut grossir, grossir et remplir votre système de fichiers. Et je suis sûr que vous voulez éviter cela.

Et beaucoup plus dangereux, beaucoup de scripts supposent que lire dans /dev/nullne lira rien; briser cette hypothèse peut entraîner des ordures aléatoires écrites dans des fichiers tout autour de votre système ... pratiquement impossible à corriger.

Et rappelez-vous que Linux est multitâche: pendant que vous jouez /dev/null, de nombreux processus sont en cours d'exécution et peuvent causer des ravages même pendant une "fenêtre d'opportunité" de quelques secondes.

Si vous voulez jouer avec /dev/nullvous pouvez créer une copie et expérimenter avec:

sudo mknod -m 0666 /tmp/null c 1 3 

Crée un /tmp/nullfichier qui fonctionne exactement de la même manière /dev/nullmais que vous pouvez manipuler et tester sans aucun risque pour votre système.


16

Il y a une grande différence entre écraser un fichier et écrire dans un fichier.

Lorsque vous écrivez quelque chose à /dev/null , par exemple,

$ echo Hello > /dev/null

... il est jeté silencieusement. Pour cela, vous devez disposer d'autorisations d'écriture /dev/null, que tout le monde possède:

$ ls -l /dev/null 
crw-rw-rw- 1 root root 1, 3 Mar 18 13:17 /dev/null

Lorsque vous écrasez /dev/null , comme vous l'avez fait avec la mvcommande, vous remplacez le fichier spécial /dev/nullpar ce que vous y avez déplacé. Ne fais pas ça! La raison pour laquelle vous aviez besoin de privilèges root est que, pour écraser un fichier, vous devez disposer d'autorisations d'écriture sur le répertoire qui contient le fichier , dans ce cas /dev:

$ ls -ld /dev
drwxr-xr-x 16 root root 4640 Mar 18 13:17 /dev

Pour restaurer /dev/null, lancez les commandes

$ sudo rm /dev/null
$ sudo mknod -m 0666 /dev/null c 1 3

(Voir aussi U & L StackExchange: Comment créer/dev/null )


8

Lorsque vous exécutez la commande

$ sudo mv test_file /dev/null

vous avez remplacé le fichier spécial /dev/nullpar votre fichier texte. Les tentatives suivantes de lecture à partir de /dev/nullrenvoient le contenu de votre fichier texte, et les programmes qui tentent de l'utiliser /dev/nullde manière normale risquent de ne pas fonctionner correctement.

Le remplacement ou la suppression de fichiers de périphérique dans /dev/requiert des privilèges de super-utilisateur. C'est pourquoi votre tentative non-sudo a échoué avec une erreur.

Voir la réponse de Benoit pour des informations sur la procédure de restauration /dev/nullmanuelle, mais étant donné que la plupart (sinon la totalité) du contenu de /dev/est gérée de manière dynamique par udev, je suspecte qu'un simple redémarrage le corrigera probablement aussi.


6

Pour répondre à votre question sur ce que vous auriez dû faire, pour supprimer un fichier, vous procédez comme suit:

rm test_file

Comme d'autres l'ont déjà indiqué, / dev / null est une destination pour la sortie des programmes.


2
Je n'ai pas voté vers le bas, mais la question ne concerne pas la suppression de fichier ... Je sais que nous utilisons rmpour supprimer des fichiers / répertoires ... Je viens de lire /dev/nullet, pour en savoir plus, j'ai essayé de déplacer des fichiers vers /dev/nullet de voir the effect .. Cette question concerne la compréhension de ce que j’ai fait de mal en déplaçant des fichiers à /dev/nullla suite de quoi je peux la lire maintenant ... La question ne porte pas sur la façon de supprimer des fichiers du système ... J'espère que c'est le cas clair ... Mais votre réponse est toujours la bienvenue et suffisante pour être conservée comme réponse ...:
Aditya

7
Pour être juste, demander "Qu'est-ce que j'ai fait de mal" demande en quelque sorte une explication de ce qui aurait dû être fait à la place. C'est probablement trivial pour la plupart des utilisateurs mais aucune des autres réponses ne l'a même mentionné.
Kapex
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.