Куди йдуть ручки відкритого файлу, коли вони гинуть?

Що відбувається з файлами, які видаляються, поки у них відкрита ручка файлу?

Мені це було цікаво ще з тих пір, як я зрозумів, що можу видалити відеофайл під час його відтворення в MPlayer, і він все ще буде відтворюватися до кінця. Звідки вона витягує дані? Це все ще йде з жорсткого диска? Чи було воно скопійовано в оперативну пам’ять, коли я видалив файл?

Якщо він все ще знаходиться на жорсткому диску, що станеться, якщо я заповнюю файлову систему, поки програма працює з читанням, що є по суті нерозподіленим простором? Якщо він буферизований в оперативній пам'яті, що станеться, якщо я промиваю буфери?

Що станеться, якщо файл знаходився на спільній доступності NFS - чи зберігається він на сервері? (Хіба це не ризик для безпеки - DoS через тони відкритих віддалених файлів?)

Ведення lsof -n |grep '(deleted)'іноді дає цікаві результати; якщо я оновлюю пакети, які замінюють спільні файли бібліотек, то запущені програми, які використовували ці бібліотеки, все одно зможуть використовувати їх так, ніби нічого не змінилося.

Питання про бонус: Чи є в цій ситуації спосіб повернути дані від мертвих?

filesystems open-files

— амфетамахін
джерело

Відповіді:

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

debugfs і подібні інструменти можуть бути використані для відновлення вмісту утворень.

— Ігнасіо Васкес-Абрамс
джерело

Це правильно, однак якщо файл все ще відкритий, ви можете отримати його назад, перейшовши до / proc / <PID> / fd, де PID - pid програми, у якій файл все ще відкритий. Цей каталог містить усі дескриптори відкритих файлів програми, і ви можете отримати доступ до них так само, як і до звичайних файлів, щоб ви могли створити жорстке посилання на "відновлення" файлу.

— Патрік

Зверніть увагу, що /procце специфічно для Linux (як це є debugfs).

— Ігнасіо Васкес-Абрамс

Solaris також має / прок, і техніка там працює чудово. Не знаєте про BSD.

— Патрік

Треба лише додати, що це приголомшливо.

— n0pe

@Patrick: Ви не можете створити жорстке посилання для "відновлення" файлу з /proc. Жорсткі посилання працюють лише в одній файловій системі, а не в файлових системах, і оскільки /procце окрема неписана файлова система, ви не можете створювати жорсткі посилання на ній. Ви можете скопіювати файл, /procпроте.

— camh

Ядро робить посилання на підрахунок посилань на inode. Дивіться мою відповідь на те, що відбувається, коли я закриваю () дескриптор файлу? .

Видалення відкритих файлів, ймовірно, не є більш ефективним механізмом DOS, ніж просто відкриття файлів. ulimitВідкритих файлів забезпечує деякий захист від цієї спроби DOS. Це стосується всіх відкритих файлів, видалених чи ні.

— BillThor
джерело

Файл стирається у файловій системі лише після зникнення кожної посилання на нього. Імена, і відкриті ручки вважаються посиланнями. Поки файл відкритий у програмі, він не видаляється, хоча більшість систем не дозволяє відтворити ім'я для нього.

Дані все ще є на диску, але файл позначений як кількість посилань 0. Якщо система виходить з ладу, fsck при наступному перезавантаженні знає, що вона повинна видалити дані. Це не призводить до відмови в службі не більше ніж видалений файл.

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

У режимі NFS, коли ви видаляєте файл, який все ще відкритий у якогось клієнта, сервер NFS перейменовує файл на сервері, але не видаляє його, поки всі клієнти не випустили файл. На мій досвід, нове ім'я є .nfs…, хоча я не знаю, чи однакове ім'я у всіх реалізаціях NFS.

— Жил "ТАК - перестань бути злим"
джерело