Куда отправляются файлы при выполнении команды rm?

Недавно я случайно сделал rmнабор файлов, и это заставило меня задуматься, где именно эти файлы заканчиваются?

То есть при работе с графическим интерфейсом удаленные файлы попадают в корзину. Что эквивалентно rmи есть ли способ отменить rmкоманду?

Нигде, ушел, исчез. Ну, более конкретно, файл становится несвязанным. Данные все еще находятся на диске, но ссылка на них удалена. Раньше можно было получить данные, но в настоящее время метаданные очищены и ничего не восстанавливается.

Нет мусорного ведра rm, и не должно быть. Если вам нужна корзина, вы должны использовать интерфейс более высокого уровня. В trash-cliUbuntu есть утилита командной строки , но большую часть времени файловые менеджеры GUI, такие как Nautilus или Dolphin, используются для обеспечения стандартной корзины. Мусорный бак сам по себе является стандартным. Файлы, удаленные в Dolphin, будут видны в Корзине от Nautilus.

Файлы обычно перемещаются куда-то, например, ~/.local/share/Trash/files/когда они удаляются. Команда rmв UNIX / Linux сравнима с командой в delDOS / Windows, которая также удаляет и не перемещает файлы в корзину. Еще одна вещь, которую нужно осознать, это то, что перемещение файла между файловыми системами, например, на ваш USB-диск, с вашего жесткого диска на самом деле является 1) копией данных файла, за которой следует 2) отсоединение исходного файла. Вы не хотели бы, чтобы ваш мусор был заполнен этими дополнительными копиями.

Для ext3 / ext4, вы можете воспользоваться функцией восстановления файлов с помощью таких инструментов , как extundelete или ext3grep , или даже пойти возиться со структурами низкого уровня вручную (не для слабонервных); для многих файловых систем вы можете попытаться найти еще не перезаписанные блоки по определенным шаблонам (например, magicrescue может искать заголовки JPEG среди прочего). Обратите внимание, что они используют эвристику для восстановления файлов из оставленных метаданных, поэтому полное восстановление не гарантируется - это скорее ставка на последний шанс (поскольку для этого требуется, чтобы некоторые следы файлов оставались в журнале, а блоки еще не были перезаписаны).

Таким образом, для всех намерений и целей файлы, удаленные с помощью rm, исчезли - вы можете попробовать такую ​​некромантию, которую предлагают эти инструменты, но не зависите от нее: это инструменты, которые нужно попробовать, когда все остальное не сработает. Лучше выкопайте свои последние резервные копии (вы делали резервные копии, верно? Хорошо, живите и учитесь ...).

Относительно устранения последствий rm:

Учитывая, что большинство файловых систем удаляют только ссылки на данные и указывают, что блоки свободны, вы можете попытаться найти данные, считываемые непосредственно с устройства. Если повезет, блоки, содержащие ваши файлы, не были востребованы для чего-то еще.

Это предполагает, что у вас есть что-то довольно уникальное для поиска, что у вас есть rootв системе, и я предполагаю, что объединение всего, что охватывает более одного блока файловой системы (вероятно, 4 КБ), может оказаться довольно трудоемким, если файловая система не справится поместить файл (ы) в смежные блоки.

Я успешно восстановил содержимое пары простых текстовых файлов, запустив строки на устройстве, на котором была файловая система, и используя grepпоиск чего-то из этих файлов с большим контекстом ( -C). (И вскоре после этого инцидента компания решила потратить некоторые ресурсы на создание резервных копий)

Всякий раз, когда вы удаляете файл с помощью rmкоманды, данные файла никогда не удаляются. Другими словами, блоки в файловой системе, содержащие данные, все еще там.

Что происходит, когда вы запускаете rmкоманду, система помечает индекс, принадлежащий этому файлу, как неиспользуемый, а блоки данных этого файла также как неиспользуемые (но не уничтоженные). Однако ext3нули большинства полей в inode, когда файл удаляется.

Эта обычная маркировка неиспользованных выполняется для скорости ... В противном случае для удаления потребуется еще некоторое время. Вот почему вы могли заметить, что удаление даже больших файлов происходит быстрее (вы можете восстановить данные, если эти блоки данных не будут перезаписаны).

Дополнительная информация: структура Inode , как работает удаление файлов

В файловых системах в стиле Unix (в том числе в Linux) файлы на самом деле не находятся «в каком-либо конкретном месте». Вместо этого система использует жесткие ссылки, чтобы указать на части того, что составляет большой блок данных. Поэтому, когда вы создаете файл, вы также создаете его первую жесткую ссылку: ту, которая фактически находится в том месте, где вы «сохранили» файл. Если вы делаете больше жестких ссылок, то, насколько известно системе, файл фактически существует в нескольких местах одновременно.

Когда вы «удаляете» файл, обычно вы фактически удаляете жесткую ссылку, существовавшую в указанном вами месте. Вот почему системный вызов для удаления файлов называется unlink(). Система фактически не удалит файл, пока на него не останется жестких ссылок. Но как только эта последняя жесткая ссылка будет уничтожена, данные будут уничтожены.

Итак, куда уходят файлы, которые вы удаляете? Если все еще существуют жесткие ссылки, они находятся там, где есть те жесткие ссылки, которые вы не удалили. Если жестких ссылок не осталось, файлы исчезли.

Посмотрите также ~ / .snapshot, если файл был недавно удален.