TTL для файлов?

[poige]

- Скачиваешь что-нибудь, ну и выбираешь (если должно отличаться от default), сколько это должно храниться. Сколько авдеевых конюшн сами бы очищались… :-)

UPD.: Кстати, подумал тут - раз уж браузеры являются основным «поставщиком», логично ожидать появления подобной фичи именно там, возможно в виде extensions.

Comments

[mithraen]

Не пройдет и тысячи лет, как линуксоиды начнут наконец-то пользоваться extended attributes... :)

Тебе никто не запрещает, к примеру, автоматически ставить такой TTL для файлов попавших в Downloads браузера, к примеру.

[poige]

Дэн, блин, неужели ты думаешь, я не знаю про xattr? Это всё напильник и детали, но меня больше интересует обдумывание концепции, а не как её реализовать.

[mithraen]

Ну тогда нужно сначала сформулировать use cases

[poige]

xattr не панацея. Могу привести пример - в *NIX у файлов есть magic bits, типа suid/sgid. А в VAX/VMS была просто центральная база, где если какому-то бинарю нужно было навешивать доп. права при запуске, он туда и вносился. Как считаешь - какой подход более pro-secure?

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

[mithraen]

EA это упрощают, с учетом того что файлик может быть перемещен, к примеру. Это-ж скрипт, а не бинарь системный.

[poige]

> с учетом того что файлик может быть перемещен, к примеру.

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

[mithraen]

Ничего, кроме необходимости при каждом запуске этот хэш считать, например.

Собственно о чем мы спорим? Все такие задачи замечательно решаются. Но могут решаться -- проще, и я об этом. А никак не о "нерешаемости".

[poige]

> Собственно о чем мы спорим?

Именно - офф-топик это всё, а не обсуждение идеи автоматического устаревания файлового контента.

[gul_kiev]

> А еще для уменьшения количества мусора в системе не хватает syscall'ов, которые позволял бы:
а) создать файл, не создавая имени (аналог open с последующим немедленным unlink);

Так ли много мусора остаётся из-за слёта процесса внутри tmpfile()?
На мой взгляд, дело не в отсутствии сисколла (который дал бы атомарность), а в том, что программисты предпочитают не заморачиваться этим мусором, и не удаляют временные файлы сразу после их создания, предпочитают mkstemp(), а не tmpfile().
Но и причины тоже понятны: атомарность - это одно, а переносимость и поддержка разными файловыми системами, включая nfs и smb - другое. И это другое обычно оказывается важнее.
То же, кстати, относится и к EA.

[mithraen]

tmpfile() многие не пользуются потому что предпочитают не использовать f*. А вот причины этому я сходу назвать не могу, кроме религиозных.

Кроме того tmpfile() не решает проблему с lock-файлами, и другими у которых важен pathname.

EA, кстати, нормально поддерживается как минимум smb. Ибо в винде и OS/2 появились (и активно используются) куда раньше чем в Linux (где они типа есть, но никто ими не пользуется).

С nfs/smb будет проблема лишь с реализацией вызова link с хэндлом в качестве параметра. И то, в принципе, это можно если надо эмулировать (при удалении файла вместо это создавать на него ссылку в отдельном каталоге). Это грязный хак, который потенциально может порождать мусор, зато это будет только в том случае, когда подобные вызовы используются поверх nfs/smb.

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