Вопросы Теги

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

Просто добавьте все файлы на командной строке. Можно ли использовать * или? или независимо от того, что Ваша оболочка позволяет как заполнитель.

Из страницы справочника:

grep [OPTIONS] PATTERN [FILE...]

средства: столько файлов, сколько Вы желаете.. или ни один, если Вы хотите к grep stdin/pipe.

15
19.12.2011, 06:53
3 ответа

inodes все еще сохраняются на диске, хотя больше жестких ссылок на inodes не существует. Они будут удалены, когда дескриптор файла будет закрыт. До тех пор файл может быть изменен как нормальные, запрещающие операции, которые требуют имени файла/жесткой ссылки.

debugfs и подобные инструменты могут использоваться для восстановления содержания inodes.

13
27.01.2020, 19:49
  • 1
    Это корректно, однако если файл все еще открыт, можно вернуть его путем движения в/proc / <PID>/fd, где PID является pid программы, которая имеет файл, все еще открываются. Этот каталог содержит все открытые дескрипторы файлов программы, и можно получить доступ к ним точно так же, как нормальные файлы, таким образом, Вы могли создать жесткую ссылку для 'восстанавливания' файла. –  Patrick 18.12.2011, 06:44
  • 2
    Действительно отметьте это /proc является определенным для Linux (как debugfs). Солярис –  Ignacio Vazquez-Abrams 18.12.2011, 06:46
  • 3
    имеет/proc также и работы техники там очень хорошо. Не знайте о BSD. –  Patrick 18.12.2011, 06:50
  • 4
    я просто должен добавить, что это является потрясающим. –  n0pe 18.12.2011, 07:07
  • 5
    @Patrick: Вы не можете создать жесткую ссылку для 'восстанавливания' файла от /proc. Жесткие ссылки работают только над той же файловой системой, не через файловые системы и с тех пор /proc отдельная неперезаписываемая файловая система, Вы не можете создать жесткие ссылки на ней. Вы могли скопировать файл прочь /proc все же. –  camh 19.12.2011, 09:12

Ядро делает подсчет ссылок на ссылках на inode. См. мой ответ на то, Что происходит, когда я закрываю () дескриптор файла?.

Удаление открытых файлов вероятно не более эффективное механизм DOS, чем просто вводные файлы. ulimit на открытых файлах обеспечивает некоторую защиту против этой попытки DOS. Это относится ко всем открытым файлам, удаленным или нет.

5
27.01.2020, 19:49

Файл только стирается в файловой системе один раз в ссылку на него, исчез. И имена и открытые дескрипторы рассчитывают как ссылки. Пока файл открыт в программе, он не удален, хотя большинство систем не позволяет Вам воссоздавать название его.

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

Вы не можете воссоздать ссылку на файл на запасе система Linux насколько я знаю (за исключением обхода драйвера файловой системы с debugfs или похожие методы), но можно восстановить содержание легко: cat /proc/12345/fd/42 где 12345 идентификатор процесса, который имеет открытый файл, и 42 число дескриптора файла.

По NFS, когда Вы удаляете файл, это все еще открыто в некотором клиенте, сервер NFS переименовывает файл на сервере, но не удаляет его, пока все клиенты не выпустили файл. По моему опыту, новое имя .nfs…, хотя я не знаю, является ли имя тем же во всех реализациях NFS.

5
27.01.2020, 19:49

Теги

Похожие вопросы