Реально восстановить удалённые файлы?

не знаю, что проще, выкачать по новой, найдя в истории браузера, или попробовать восстановить

Если это что-то из инета, да ещё и не очень давно скачанное (а значит велик шанс, что оно в интернете всё ещё есть), то конечно проще выкачать.

делал fstrim другого раздела на этом SSD

Другой раздел на этот никак не влияет.

достаточно ли сделать dd копию нужного раздела, или надо всего диска?

Достаточно этого раздела.

есть ли смысл потратить время?

Если это не уникальный контент, созданный тобой, или дрвевний и нигде не доступный, то конечно нет. Проще найти и скачать заново.

Если это не уникальный контент, созданный тобой, или дрвевний и нигде не доступный, то конечно нет. Проще найти и скачать заново.

С другой стороны это может быть полезно в качестве упражнения.

вот чтобы хотя бы имена узнать в такой ситуации, делай по крону ls -laR / > /ls_${date}_backup.lz

С другой стороны это может быть полезно в качестве упражнения.

Которое будет только тратой времени.

Было дело грохнул случайно каталог на HDD с ext4. Тут же отмонтировал этот диск и натравил на него тестдиск. Так он ничего из удаленного не нашел, вообще. Благо там хлам всякий был. Хотя тем же тестдиском не раз восстанавливал по долгу службы удаленные пользователями файлы с флешек и cd карт (fat32). После этого случая создалось впечатление, что с ext4 ничего не достать после удаления.

Потому что имя файла и соотвествующий ему inode хранится не в самом файле, а в директории, где этот файл лежит. Когда говоришь rm удаляется именно эта запись в каталоге. Так устроена ext4(возможно и не только эта ФС).

Сейчас покопался и выяснил, что просто кто-то (работающий, возможно, на гугл, и, похоже, это женщина) пришёл и в отсутствие каких либо жалоб, взял и отправил патч, чтобы затирать имя файла, что и прилетело нам всем тихо в 5.13. И грозно пообещал, что ещё отправит патч, чтобы затереть самое последнее упоминание об этой информации в журнале. И он потом тоже был принят. Повезло ещё, что эту новую функцию не дёргают автоматом из ядра, а только из пространства пользователя.

Чего дёргают из пространства пользователя? Неужели новый сисколл? Сомнительная история.

Не, просто ioctl.

Что за бред? В архитектуре файловых систем ext* испокон веков заложено, что имя файла хранится в директории. Команда rm(remove) удаляет запись с этим именем из каталога, а не удаляет сам файл(delete). Это было придумано, когда гугла ещё не существовало. А, возможно, это было придумано ещё и когда Linux'а не было, на других файловых системах.

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

Всё прекрасно известно.

В каталоге запись вида

filename inode_id

В inode структура с данными о файле. Среди прочего там есть флаг занят он или свободен. Имени там нет.

Удаляешь файл, удаляется запись из каталога. Там нет опции пометить её как-то. Это просто два значения - имя и inode_id. Физически файл остаётся. Если кто-то ещё использует файл, в inode флаг остаётся в значении «занят». Как только программа отпустит этот файл, значение флага в inode станет «свободен». Но имени нет уже нигде. Он исчезло, как только ты сказал на файл rm.

Алгоритм сложнее, если на этот файл были хардлинки. Но это отдельный вопрос, который выходит за рамки данной темы.

хардлинки

А я вот постоянно сталкиваюсь с симлинками. Делаю их сам, или они приходят в каком-нибудь пакете, например. Но вот именно хардлинк я, если и встречал, то это было настолько давно, что я вспомнить не могу, когда это было :)

Собственно, вот (github.com).

И это ещё расширенный формат. Там же есть и упрощённый, где полей меньше.

Логическую структуру дерева директорий я знаю, не надо мне её расписывать. А вот действие «удалить запись» никакой строго заданной реализации не имеет. Какая она в ext4 я не знаю, а ты знаешь? Пока что ты обходишься только общими словами.

Я сталкивался, но тоже редко. А симлинки, да. С ними постоянно работают все, даже если об этом не знают. :)

Ну да, только я же туда лазаю раз в тысячу лет, да и хардлинки хорошо маскируются под обычные файлы :)

Удаляешь файл, удаляется запись из каталога. Там нет опции пометить её как-то. Это просто два значения - имя и inode_id.

Опция пометить есть: обнуляется inode_id.

И чтобы что? У тебя останется имя, не привязанное к inode. Что с ним делать? Это не «пометить». Это просто бессмысленное действие.

plocate / slocate / locate

А я вот постоянно сталкиваюсь с симлинками. Делаю их сам, или они приходят в каком-нибудь пакете, например. Но вот именно хардлинк я, если и встречал, то это было настолько давно, что я вспомнить не могу, когда это было :)

хардлинк не является чем-то отличным от первичной записи об имени файла.

А симлинки, да. С ними постоянно работают все, даже если об этом не знают. :)

С хардлинками тоже «даже если об этом не знают» в случае если забыли ключик -s указать :)

тоже вариант, но сработает только если заметил быстро, а не когда база обновилась.

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

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

Простите мою неосведомленность, а это зачем?

Вообще . и .. это тоже хардлинки, так что сталкиваетесь постоянно :)

user@docker:~/tmp/d1$ ls -la
total 8
drwxrwxr-x 2 user user 4096 окт 10 16:22 .
drwxrwxr-x 5 user user 4096 окт 10 16:36 ..

user@docker:~/tmp/d1$ mkdir ../dd

user@docker:~/tmp/d1$ ls -la
total 8
drwxrwxr-x 2 user user 4096 окт 10 16:22 .
drwxrwxr-x 6 user user 4096 окт 10 16:36 ..

А я вот постоянно сталкиваюсь с симлинками. Делаю их сам, или они приходят в каком-нибудь пакете, например. Но вот именно хардлинк я, если и встречал, то это было настолько давно, что я вспомнить не могу, когда это было :)

Я делаю довольно много хардлинков либо сам, либо с помощью jdupes.

Реже, наверное, чем симлинки, впрочем.

btrfs со снапшотами не нужен, говорили они…

да и хардлинки хорошо маскируются под обычные файлы :)

Это и есть обычные файлы. Просто у файла больше одного имени.

Я не о теории, а о практике, как оно реализовано. Кажись, на ЛОРе сравнительно недавно упоминали, что если почистить здоровенный каталог, то быстрее с ним работать всё равно будет нельзя.

Это связано с индексацией. Старая известная проблема. Правда, давно с этим не сталкивался(вроде бы придумали уже механизмы автоматической очистки). И не «здоровенный каталог», а «каталог в котором очень много файлов». Но в этом индексе всё-равно нет имён файлов. Это именно что перечесление inode. Точный механизм сейчас не смогу объяснить без заглядывания в код.

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

Чтобы поймать этот эффект нужно было просто огромное количество файлов в одной директории. Повторюсь, уже много лет с такой проблемой не сталкивался.