Почему перемещение каталогов в / dev / null опасно?

/dev/null - это просто файл, это файл с особым символом, но он не менее связан правилами, которые должны следовать файлам. При этом вы никогда не сможете запустить эту команду:

$ mv ~ /dev/null

Команда mv не позволит этого, так как вы перемещаете каталог в файл, что просто не имеет смысла контекстуально и mv знает это.

Пример

$ mkdir dir
$ touch afile
$ mv dir afile
mv: cannot overwrite non-directory ‘afile’ with directory ‘dir’

Вы также не можете скопировать на /dev/null, если это файл символа, если вы попытаетесь скопировать обычный файл на

$ cp ~/bzip2_1.0.6-4_amd64.deb /dev/null
$ ls -l |grep null
crw-rw-rw-  1 root root        1,   3 Mar 16 14:25 null

О том, что вы можете сделать только этот файл, это копировать mv поверх другого файла или удалять его.

$ mv /path/to/afile /dev/null

После этой команды [ f11] является обычным файлом. Самый опасный эффект этого изменения заключается в том, что /dev/null не должен выводить никаких данных, поэтому ряд сценариев оболочки предположит, что

`... < /dev/null` 

эквивалентен «ничего». Прерывание этого предположения может привести к случайным данным (ну, данные, которые последний процесс написал в `/ dev / null '), вставлены в системные файлы по всей системе, что может привести к совершенно сломанной и невосстановимой системе. 7]

Вы можете записывать файлы или другие входные потоки в /dev/null, но не в каталоги. Если вы попытаетесь переместить каталог в /dev/null, он сообщит об ошибке, так как /dev/null не является каталогом, а файлом.

Однако, поскольку вы хотите поэкспериментировать с /dev/null, вы сначала предложили узнать о последствиях перемещения файла для перезаписи /dev/null и о том, как восстановить из этой ситуации:

Я могу читать / dev / null; как это исправить?

Как предложил @Rmano в этом ответе на этот вопрос, чтобы поэкспериментировать с /dev/null, мы должны скорее создать его копию, а затем провести эксперимент. Итак, давайте создадим /tmp/null и используем его для наших экспериментов:

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

Теперь, /tmp/null является нашей /dev/null для всех целей:

Давайте создадим a test_file и test_dir внутри каталога с именем ask_ubuntu.

$ mkdir ask_ubuntu
$ cd ask_ubuntu
$ touch test_file
$ mkdir test_dir
$ echo "Let us test if we can recover our test_file." > test_file

Ниже показано содержимое каталога ask_ubuntu:

$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:10 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir
-rw-r--r-- 1 aditya aditya    0 Mar 18 17:10 test_file

Теперь попробуйте для перемещения нашего test_file в /tmp/null и просмотра содержимого ask_ubuntu:

$ sudo mv test_file /tmp/null   # This succeeds
$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:12 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir

Команда завершается успешно, а test_file больше недоступна. Теперь попробуйте переместить test_dir в /tmp/null, что не удастся:

$ sudo mv test_dir/ /tmp/null 
mv: cannot overwrite non-directory ‘/tmp/null’ with directory ‘test_dir/’

test_dir все еще присутствует внутри ask_ubuntu:

$ ls -la
total 12
drwxr-xr-x 3 aditya aditya 4096 Mar 18 17:12 .
drwxr-xr-x 4 aditya aditya 4096 Mar 18 17:10 ..
drwxr-xr-x 2 aditya aditya 4096 Mar 18 17:10 test_dir

Теперь, давайте посмотрим, можем ли мы восстановить наш test_file из /tmp/null:

$ cat /tmp/null
Let us test if we can recover our test_file.

Итак, он все еще существует, и /tmp/null, который был специальным файлом, был перезаписан, и он стал как любой другой стандартный файл. Мы можем восстановить наш файл, скопировав /tmp/null так же, как и любой другой файл:

$ cp /tmp/null our_test_file
$ cat our_test_file
Let us test if we can recover our test_file.

Файл восстановлен.

Примечание:

Если вы этого не сделали создайте /tmp/null и попробуйте эти команды непосредственно с помощью /dev/null; убедитесь, что вы восстановили файл (если вам нужно), запустив cp /dev/null our_test_file; и восстановить /dev/null для целей, которые он существует в нашей системе, выполнив следующие команды, как указано в связанном вопросе, как можно скорее:

$ sudo rm /dev/null
$ sudo mknod /dev/null c 1 3
$ sudo chmod 666 /dev/null

Заключение:

[d3 ] Я могу читать / dev / null; как это исправить? Что касается файлов, то при прямом перемещении файлов на /dev/null вы можете восстановить его, как показано выше. Однако есть два исключения: в течение периода вы запускаете sudo mv test_file /dev/null и cp /dev/null our_test_file, если любой корневой скрипт в системе перезаписывает его, запустив echo "Whatever text the root script wants to send to /dev/null" > /dev/null (или другие подобные команды). Тогда у нас нет простого способа восстановить наш файл. Если вы перезагрузите систему между запусками этих двух команд. /dev/null воссоздается при загрузке, поэтому наш файл теряется, когда мы закрываем компьютер. Но если вы хотите восстановить потоки ввода, такие как echo "Stream this line to /dev/null" > /dev/null, вы не сможете восстановить это, поскольку /dev/null является специальным файлом для удаления ненужных файлов и потоков ввода, и, как упоминается в статье Wikipedia, он не предоставляет никаких данных процессу который читается из него.

Ссылка: @Rmano

Все отправленные в /dev/null молча отбрасываются. Если вы наберете:

echo "Hello World"

, вы получите Hello World на экране. Если вы наберете:

echo "Hello World" >/dev/null

, вы ничего не получите на экране.

Но в случае команды move команда mv попытается заменить файл / dev / null по каталогу, что невозможно. Поскольку все файлы в Linux, / dev / null - это файл. Специальный, конечно (файл устройства), специальный файл, позволяющий получить доступ к части оборудования (например, диски, разделы, звуковые карты, последовательные порты, ...). В случае / dev / null это не связано с каким-либо оборудованием, поэтому данные, отправленные на него, молча отбрасываются. Вот почему «они», возможно, назвали это черной дырой.