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

<p>недавно я случайно сделал <code>rm</code> для набора файлов, и это заставило меня задуматься, где именно эти файлы заканчиваются?</p><p>то есть при работе с графическим интерфейсом удаленные файлы попадают в корзину. что эквивалентно для <code>rm</code> и есть ли способ отменить команду <code>rm</code>?</p>

<p>нигде, ушел, исчез. ну, более конкретно, файл становится несвязанным. данные все еще находятся на диске, но ссылка на них удалена. раньше можно было получить данные, но в настоящее время метаданные очищаются и ничего не восстанавливается.</p><p>для <code>rm</code> нет корзины, и ее не должно быть. если вам нужна корзина, вы должны использовать интерфейс более высокого уровня. в ubuntu есть утилита командной строки в <code>trash-cli</code>, но большую часть времени файловые менеджеры с графическим интерфейсом, такие как nautilus или dolphin, используются для обеспечения стандартной корзины. мусорный бак сам по себе является стандартным. файлы, удаленные в dolphin, будут видны в корзине от nautilus.</p><p>файлы обычно перемещаются куда-то вроде <code>~/.local/share/trash/files/</code> при загрузке. команда <code>rm</code> в unix/linux сравнима с <code>del</code> в dos/windows, которая также удаляет и <strong>не</strong> перемещает файлы в корзину. еще одна вещь, которую нужно осознать, это то, что перемещение файла между файловыми системами, например на ваш usb-диск, с вашего жесткого диска на самом деле является 1) копией файловых данных, за которыми следует 2) отсоединение исходного файла. вы не хотели бы, чтобы ваш мусор был заполнен этими дополнительными копиями.</p>

<p>для ext3/ext4 вы можете попробовать восстановить файлы с помощью таких инструментов, как <a href="http://extundelete.sourceforge.net/">extundelete</a> или <a href="http://code.google.com/p/ext3grep/">ext3grep</a> или даже перейти <a href="http://www.giis.co.in/debugfs.html">возиться</a> со структурами низкого уровня - <a href="http://www.xs4all.nl/~carlo17/howto/undelete\_ext3.html">вручную</a> (не для слабонервных); для многих файловых систем вы можете попытаться найти еще не перезаписанные блоки по определенным шаблонам (например, <a href="http://www.irongeek.com/i.php?page=backtrack-3-man/magicrescue">magicrescue</a> может искать заголовки jpeg, среди прочего). обратите внимание, что они используют эвристику для восстановления файлов из оставленных метаданных, поэтому полное восстановление не гарантируется - это скорее ставка на последний шанс (поскольку для этого требуется, чтобы некоторые следы файлов оставались в журнале, а блоки еще не были перезаписаны).</p><p>таким образом, для всех целей и целей файлы, удаленные с помощью <code>rm</code>, пропали - вы можете <em> попробовать </em> такую некромантию, которую предлагают эти инструменты, но не не зависит от этого: это инструменты, которые нужно попробовать, когда все остальное терпит неудачу. лучше выкопайте свои последние резервные копии (вы делали резервные копии, верно? хорошо, живите и учитесь ...).</p>

<p>относительно отмены эффектов <code>rm</code>:</p><p>учитывая, что большинство файловых систем удаляют только ссылку на данные и указывают, что блоки свободны, вы можете попытаться найти данные, считываемые непосредственно с устройства. если повезет, блоки, содержащие ваши файлы, не были востребованы для чего-то еще.</p><p>это предполагает, что у вас есть что-то довольно уникальное для поиска, что у вас есть <code>root</code> в системе, и я предполагаю, что объединение всего, что охватывает более одного блока файловой системы (вероятно, 4 кб), может оказаться довольно трудоемким, если файловая система не смогла поместить файл (ы) в непрерывные блоки.</p><p>я успешно восстановил содержимое пары простых текстовых файлов, запустив строки на устройстве, на котором была файловая система, и используя <code>grep</code>, ища что-то из этих файлов с большим контекстом (<code>-c</code>). (и вскоре после этого инцидента компания решила потратить некоторые ресурсы на создание резервных копий)</p>

<p>всякий раз, когда вы удаляете файл с помощью команды <code>rm</code>, данные файла никогда не удаляются. другими словами, блоки в файловой системе, содержащие данные, все еще там.</p><p>что происходит, когда вы запускаете команду <code>rm</code>, система помечает индекс, принадлежащий этому файлу, как неиспользуемый, а блоки данных этого файла также как неиспользуемые (но не уничтоженные). однако <code>ext3</code> обнуляет большинство полей в inode при удалении файла.</p><p>эта нормальная маркировка неиспользованных выполняется для скорости ... в противном случае для удаления потребуется еще некоторое время. вот почему вы могли заметить, что удаление даже больших файлов происходит быстрее (вы можете восстановить данные, если эти блоки данных не будут перезаписаны).</p><p>дополнительная информация: <a href="http://slashroot.in/inode-and-its-structure-linux">структура inode</a> , <a href="http://slashroot.in/how-does-file-deletion-work-linux">как работает удаление файла</a> </p>

<p>в файловых системах в стиле unix (в том числе в linux) файлы на самом деле не находятся "в каком-либо конкретном месте". вместо этого система использует жесткие ссылки, чтобы указать на части того, что составляет большой блок данных. поэтому, когда вы создаете файл, вы также создаете его первую жесткую ссылку: ту, которая фактически находится в том месте, где вы "сохранили" файл. если вы делаете больше жестких ссылок, то, насколько известно системе, файл фактически существует в нескольких местах одновременно.</p><p>когда вы "удаляете" файл, обычно вы фактически удаляете жесткую ссылку, существовавшую в указанном вами месте. вот почему системный вызов для удаления файлов называется <code>unlink()</code>. система фактически не удалит файл, пока на него не останется жестких ссылок. но как только эта последняя жесткая ссылка будет уничтожена, данные будут уничтожены.</p><p>итак, куда уходят файлы, которые вы удаляете? если все еще существуют жесткие ссылки, они находятся там, где есть те жесткие ссылки, которые вы не удалили. если жестких ссылок не осталось, файлы исчезли.</p>

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