Интересно, как это работает.

[beldmit]

Из Changelog новой версии ядра Linux (3.11, "Linux for workgroups"):

В системные вызовы open() и openat() добавлена поддержка флага O_TMPFILE, позволяющего передать файловой системе информацию о создании временного файла, не видимого в иерархии ФС, что позволяет применить для данного типа файлов отдельные оптимизации. Создаваемые при помощи O_TMPFILE временные файлы не имеют имени, в качестве пути передаётся только директория. Создание невидимого временного файла без имени позволяет разработчикам приложений не задумываться о возможных уязвимостях, таких, как атака через символические ссылки;

В ряде мест такая возможность сильно упростит жизнь. Но до широкого распространения, боюсь, еще долго.

Comments

[pukkallo.livejournal.com]

По RSX-11 не скажу - прошла мимо. Однако, ЕМНИП, запись в каталоге в RT-11 имела в качестве своей составляющей ссылку на начало физического положения, а файл открывался в самом большом из доступных пустых мест (которые тоже писались в каталог наравне с файлами). Поэтому её финализация по close была естественной для модификации смежной пустой записи. Кроме того, в RT была какая-то команда (не помню точно) - некоторый аналог sync в UNIX, которая обновляла именно запись в каталоге на данный момент и позволяла не потерять сделанных изменений. Или мы это reopen делали ... давно было. Кстати, достоинство существования старого файла при любых сбоях была весьма приятственной особенностью. После смены религи мне этого регулярно не хватало.

Впрочем, я как-то больше пошел по прикладным, поэтому многих подробностей не помню. Надо поспрошать брата, который во времена оные написал на ассемблере аналог squeeze, который использовался на ... Откат был невозможен, при сбое умирало все, но работало раз в 5 быстрее :)

[kouzdra.livejournal.com]

Поэтому её финализация по close была естественной для модификации смежной пустой записи.

Разумеется - так для close подобные функции естественны довольно таки



А в RSX каталог был просто файлом с записями по 16B емнимп, которые устанвливали соответствие имяфайла -> его ID - (ID - пара - порядковый номер, контрольное значение, потом появился третий - номер устройства кажется, или хоста).

Файловый процессор в принципе умел по отдельному каталогу искать (хотя я так и не очень понял зачем), а уже работа с вложенными каталогами делалась просто на уровне user space библиотеки (что забавно - хотя структура была формально двух уровневой - главный каталог - пользовательские - зашито было исключительно на уровне соглашений об именовании файлов и соответствующих функций. Уже утилита Verify (тамошний fsck) работала с произвольной вложенностью каталогов и произвольными же их именами.

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