[dreams] линковка файла в каталог по fd

[Valentin Nechayev]

Hi,

Вот интересную тему поднял коллега:

Почему в позиксе нет функции flink(int fd, const char *name)?
Её отсутствие не даёт возможности атомарного создания файла с нужным
содержимым. Чтобы можно было создать inode без имени, наполнить его, и
присвоить имя только когда он уже готов для дальнейшей обработки. Hет - нужно
временное имя, потом rename(), плюс чистка от временных файлов, образовавшихся
при обрыве связи, защита от обработки временных файлов, и так при каждом cp,
scp, ftp, wget... :-(

(тут: http://gul-tech.livejournal.com/9541.html)

А действительно - если мы в принципе позволяем удалённые из всех каталогов, но
ещё существующие файлы на FS, почему бы эту возможность не довести до
логического завершения и не создавать для таких новые имена?


-netch-

... Это были глаза профессора Плейшнера.

[Serguei E. Leontiev]

Валентин, привет,

Post by Valentin Nechayev
Почему в позиксе нет функции flink(int fd, const char *name)?

Зададим себе три неприличных вопроса: http://www.anekdot.ru/id/605194/

Почему? IMHO, потому что POSIX традиционно не требует возможности обратного
преобразования из inode в имена (mount вне POSIX, fattach() сдох вместе со
STREAMS). Так что это некая новая сущность, которая, ко всему прочему, ещё
потребует специального open().

Post by Valentin Nechayev
Её отсутствие не даёт возможности атомарного создания файла с нужным
содержимым. Чтобы можно было создать inode без имени, наполнить его, и
присвоить имя только когда он уже готов для дальнейшей обработки. Hет - нужно
временное имя, потом rename(), плюс чистка от временных файлов, образовавшихся
при обрыве связи, защита от обработки временных файлов, и так при каждом cp,
scp, ftp, wget... :-(

Зачем? Hа мой не просвещённый взгляд, можно поставить три цели:
1. Если 'cp path1 path2' успешно, то всегда 'cmp path1 path2'. Hо в общем
случае, особенно, в современных условиях, эта цель недостижима;

2. Если 'cp path1 path2' успешно, то в некотором смысле
'VALIDATE-FILE-CONTENT path2'. Её, конечно, можно достичь тем или иным
способом, но так ли часто она нужна сама по себе? К примеру, в языке C
только немногие типы обладают подобным свойством, аналогично и от "scp,
ftp, wget" никто не ждёт его выполнения;

3. Если 'cp -R dir1 dir2' успешно, то в некотором смысле
'VALIDATE-DIR-CONTENT dir2'. Более интересное свойство, но рассматриваемый
flink() не приближает нас реализации данной цели, а скорее, отдаляет от
неё.

Post by Valentin Nechayev
(тут: http://gul-tech.livejournal.com/9541.html )
А действительно - если мы в принципе позволяем удалённые из всех каталогов, но
ещё существующие файлы на FS, почему бы эту возможность не довести до
логического завершения и не создавать для таких новые имена?

Что стоило бы сделать или куда бредём?

Бредём мы в сторону многопоточной работы, соответственно, всяких блокировок
низкого уровня нам не нужно. unlink() здесь "в тему", типа сборщик мусора.
А вот linkf() не очень, для lock-free алгоритмов больше нужен аналог LL/SC
или, на худой конец CMPXCHG.

В прочем, ещё более полезными и не менее масштабируемыми кажутся расширения
а ля SQL START TRANSACTION (по сути это более интелектуальный LL/SC),
которые, вполне вероятно, можно реализовать с помощью демона (или модуля
ядра) над ZFS.