2013-08-12 4 views
8

Есть ли способ создать файл в Linux, который ссылается на определенный iNode? Возьмите этот сценарий: есть файл, который находится в процессе написания (возможно, журнал), и конкретный файл удален , но ссылка в каталоге/proc по-прежнему указывает на него. В этом случае нам нужна не голая копия, а жесткая ссылка на него, поэтому мы можем иметь будущие модификации и самую последнюю модификацию до закрытия процесса, а система удалять его.Linux удаленный файл восстановления

Если у нас есть номер iNode, есть ли способ достичь этой цели?

ответ

4

Вы можете использовать LSOF для восстановления удаленных файлов (иногда) ...

> lsof | grep testing.txt 
less 4607 juliet 4r REG 254,4 21 
     8880214 /home/juliet/testing.txt (deleted) 

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

> ls -l /proc/4607/fd/4 
lr-x------ 1 juliet juliet 64 Apr 7 03:19 
     /proc/4607/fd/4 -> /home/juliet/testing.txt (deleted) 
> cp /proc/4607/fd/4 testing.txt.bk 

http://www.linuxplanet.com/linuxplanet/tips/6767/1

Наслаждайтесь

+1

Гасп. Ты прав. Я думал, что просто проверял это, и это не сработало. NTL: ОП попросил жесткую ссылку, а конкретно не копию. –

3

Это всегда трудно ответить на вопрос, как «я могу сделать» уверенно отрицательно. Но, насколько я вижу, ни/sys/nor/proc не обеспечивают сопоставление открытых дескрипторов файлов, которые не являются символическими ссылками. Я предполагаю, что «НО ссылка в каталоге/proc все еще указывает на нее», вы имеете в виду, что/proc // fd/entries выглядят как символические ссылки? Я почти уверен, что вы не можете восстановить исходный файл.

Я беру это назад: Как пользователь user2676075 указал, копирование действительно работает. Просто скрепление не ...

ОБНОВЛЕНИЕ: Если вы думаете об этом, это вполне логично.

  • /proc и/sys - это файловые системы, отличные от вашего жесткого диска. Таким образом, они не могут предоставить такие файлы, как записи в каталоге, которые можно жестко привязать к месту назначения на жестком диске.
  • Элементы/proc/*/fd/делают вид, что символические ссылки, но на самом деле они разные, иначе копирование не будет работать. Я думаю, что они притворяются символическими ссылками для предоставления значимой информации с помощью «ln -l».

  • Что касается (отсутствующей) способности HardLink к некоторому инода (скажем, с каким-то системным вызовом): Это не может быть частью ядра или VFS-интерфейс, по следующим причинам:

    • Это нарушит целостность файловой системы. Файловая система не должна хранить блоки дисков, которые полностью удалены так же, как и файлы, которые сохраняются.

    • Индексы могут быть полностью виртуальной концепцией, чтобы идентифицировать «слот, в котором хранится поток данных». Я предполагаю, что могут быть реализации, у которых возникла бы проблема с преобразованием слота, который не имеет ссылки на слот, на который ссылаются чтобы по имени в файловой системе.

    Признается дело против возможности такого системного вызова не пропускает воду. Но, учитывая текущее состояние интерфейса VFS (который AFAIR не предусматривает такой вызов), это будет тяжелым бременем для любой реализации файловой системы (включая, например,распределенные файловые системы) для предоставления вызова для связывания файла в каталог с помощью inode.

ATM Интересно, если вы звоните fstat до и после удаления последней ссылки на самом деле требует, чтобы вернуть ту же инф.узлы информации ... т

+0

Причина, по которой hardlink-to-inode не существует, заключается в том, что она позволит людям получить доступ к файлам, которые им не нужны. Каталог 700 делает все под его частным, если вы не можете обойти его с номером inode в качестве аргумента для ссылки (2). Что было бы хорошо для этой ситуации, это ссылка (2) с использованием дескриптора открытого файла. Хотя даже это могло бы открыть новые вещи, которые могли бы сделать процессы, если они были начаты с открытого fd в файле с более длинным доступом или в том, который вы не могли открыть самостоятельно. Кроме того, семантика удаления: дисковое пространство живет до последней ссылки И последний открытый fd И последний mmap исчезает. –

14

Поскольку нет Системного вызова, который включает в себя инод потому что это концепция extX fs и не является хорошей практикой, сделайте печную трубу, но она должна создать цепочку ответственности (как предлагает MEL), есть только Ответ # ответ на этот вопрос, потому что на уровне VFS мы обрабатываем путь и имена файлов а не других внутренних представлений.

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

tail -c+1 -f --pid=PID /proc/PID/fd/FD > /path/to/the/copy 

где PID является PID процесса, которые имеют удаленный файл все еще открыт, а FD - его номер дескриптора файла. С -f хвост открывается и удерживает файл, чтобы отобразить дополнительную модификацию, с -c + 1 начните с «хвоста» с первого байта и с -pid = PID хвост сообщается, чтобы выйти, когда выход pid ,

+0

inodes не являются специфическими для ext2/3/4. Они являются частью спецификации POSIX для того, как работают системные вызовы, такие как stat (2), и как вы находите hardlinks. Но, к сожалению, вы правы, что, похоже, нет никакого способа сделать ссылку из/proc/PID/fd/FD в реальный файл, просто откройте ее для чтения/записи. Если бы был только системный вызов типа link (2), в качестве источника использовался дескриптор открытого файла, а не путь. –

 Смежные вопросы

  • Нет связанных вопросов^_^