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

98

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

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

boehj
источник
3
вот возможный дубликат. отменить в Linux . Но я не совсем уверен, что файлы куда-то сильно отличаются от того, есть ли способ отменить.
ксенотеррацид

Ответы:

120

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

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

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

penguin359
источник
4
Большое спасибо за ясное объяснение. Я не возражаю против использования CLI, мне просто нужно быть немного более осторожным при использовании подстановочных знаков. :)
Boehj
16
Я бы с осторожностью использовал что-то вроде libtrashизменения поведения rm. Множество сценариев используются rmдля очистки файлов, и вы не хотите, чтобы они отображались в Корзине. Я рекомендую использовать выделенную команду, как trashиз trash-cliпакета. @pedro Я должен добавить, что однажды я создал файл * в моем домашнем каталоге. Я случайно цитировал *, когда я не должен был создавать его, поэтому я решил удалить его с помощью rm * естественным образом. Когда я понял, что я сделал, я быстро убил команду, но она уже удалила несколько файлов в моем домашнем каталоге.
penguin359
4
Очень редко иметь что-то вроде мусорной корзины в оболочке, поэтому, если вы добавляете ее на свой локальный компьютер и привыкаете к ней или даже зависите от нее в своей повседневной работе. Вы можете столкнуться с проблемами при использовании некоторых других 99% unix: s без одного ...
Йохан,
3
Я думаю, что главная идея здесь в том, что мне нужно прекратить CLI'ing в выходные и уделять больше внимания.
Boehj
2
В соответствии с тем, что сказал @Johan, RedHat обычно (до сих пор делает?) Устанавливает псевдонимы для команд, таких как cp, и mv, cp -iи mv -iпри запуске от имени пользователя root. Это меняет поведение по умолчанию, поэтому эти команды всегда будут спрашивать перед перезаписью существующих файлов. Некоторые системные администраторы рекомендовали специально удалять эти псевдонимы, чтобы в конечном итоге вы не ожидали такого поведения, которое может привести к летальному исходу в другой системе, которая следует стандартному поведению.
penguin359
11

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

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

Piskvor
источник
2
Для ценных текстовых данных вы всегда можете использовать любой надежный инструмент общего назначения (даже emacs или perl) для поиска «необработанного устройства» на диске, на котором находится удаленный файл, и поиска известных строк; Таким способом я восстановил документы Word для людей; они теряют наценку, но могут восстановить большую часть текста. Очевидно, что это аварийное восстановление, а не «Отмена».
Алексис
Надлежащая ссылка «вручную»: web.archive.org/web/20131221183925/http://…
sjas
8

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

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

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

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

Кжетил Йоргенсен
источник
Это немного сложнее, например, путем ext3 обнуления указателей блоков в inode, но да, прямой поиск файлов может работать - если они достаточно малы или размещены в непрерывном блоке. Иногда это называется вырезкой из файла, и есть такие инструменты, magicrescueкоторые пытаются найти изображения или звуки по их характерным образцам.
Писквор
6

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

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

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

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

Сарат
источник
... если файл явно не помечен chattr +sатрибутом ("shred"). Он указывает файловой системе специально перезаписывать этот файл нулями при удалении. Только некоторые файловые системы будут поддерживать этот атрибут.
TelcoM
3

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

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

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

Ложка
источник
0

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

Энди
источник
4
Это будет работать, только если у вас есть какая-то волшебная файловая система, которая предоставляет эту функцию (например, NetApp), или если вы используете специальную версию rm.
Mattdm