Время жизни файлового дескриптора

когда прибьёшь приложение?

Да, все так.

прибьёшь

Не, ну это понятно. Будем считать, что я создаю вселенную и демон работать будет вечно:)

Да

Хорошо. Спасибо...

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

О! Прикольно. Я об этом не подумал. К счастью файл, который я собираюсь читать, удалить сложновато. Он в /proc находится:)

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

Файл могут удалить снаружи, если ты не повесил эксклюзивный лок

Рельно он не удалится пока его не закроет последний процесс. На файловой системе его видно не будет, но он все еще будет существовать.

GateKeeper
Файл могут удалить снаружи, если ты не повесил эксклюзивный лок >(правда, не помню, руту этот лок - указ, или нет). Хотя там всё >просто, ловишь ошибку, сравниваешь ее код, в общем обычная веселуха.

Если файл удалят - ты об этом даже не узнаешь, продолжишь писать и чтать из дескриптора как ни в чем не бывало.

Нок ак только сделаешь close() данные исчезнут с диска.

А что ты подразумеваешь под «жизнью» дескриптора? Возможность читать файл из него? Или явное уничтожение структуры, ассоциированной с ним, и перенацеливание его на какой-нить другой объект?

пофиг. никакой ошибки не будет.

Возможность читать файл из него?

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

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

Плюсую ваш вопрос.

О как, потестил - точно так. Всех насильно в inotify загоняют? Реальные псоны там у финошведа, по хардкору всё делают.

Реальные псоны там у финошведа, по хардкору всё делают.

Учите матчасть. Это не особенности линукса, а описанное POSIX'ом поведение.

http://pubs.opengroup.org/onlinepubs/009604599/functions/unlink.html

Тогда в позиксе реальные псоны. Какая разница. Я сказал «Удалить этот 2-х гиговый файл, мне именно 2-х гиг не хватает», оно сказало «окээээй», даже изменило stat-структуру у хост-каталога, ан нет... места больше не стало. Как корзина шиндош, честное слово.

Этому поведению 50 лет в обед, как Вы могли этого не знать? :)

Файла это именованное пространство на диске с неограниченным количество имён и множеством возможных открытых дескрипторов, с чего бы его освобождать после удаления одного из множества имён?

Основание простое: Единственное, что связывает множество блоков на устройстве со статусом «занято» - множество связанных с этими блоками ссылок (файлов), т.е. собственно файлов и хардлинков. Удаление последней ссылки на эти блоки из иерархии ссылок должно трактоваться как однозначное требование о высвобождении этих блоков (для простоты - изменения их статуса на «свободно»).

Переименование файла. Всё остается на месте. Блоки заняты, поменяли текстовое представление ссылки на набор блоков (тем более, что дескриптор не к имени привязывается).

Открытые дескрипторы: инвалидировать по аналогии с обрывом сетевого соединения (между ними, кстати, вообще почти нет разницы с логической точки зрения), более того, umount -f в некоторых случаях к инвалидации этих дескрипторов и приводит, чем не rm -f /some/file не то же самое, что umount -f /some? Или более жесткий случай с исчезновением блочного устройства из пространства ядра? Нормально же всё, инвалидирует дескрипторы, всё ништяк.

В общем, да, до сих пор не подозревал о такой подставе со стороны, видимо обкурившихся позикс-боев.

Дескриптор fd будет жить пока я не сделаю close()?

/ thread