С каждым днем все больше и больше мечтаю о поддержке тегов в ФС.

Дерево директорий - слишком ригидная система иногда, а ссылки не всегда помогают.

@n0icz заразила меня.

@n0icz я вот че подумал, это же даже не настолько было бы сложно реализовать и на старой доброй Ext4, не прибегая к каким-то новым ФС с крутой системой метаданных.

Мы, например, знаем, что имя файла (как и его адрес в дереве директорий) это технически просто хардлинк на некоторую область на диске, и таких хардлинков может быть сколько угодно. То есть, по сути это уже и есть готовая система тегов, надо просто сделать ее чуточку комфортнее.

Например, сделать в корне специальную директорию "/tags", в ней создать поддиректории по именам тегов, а эти директории забить хардлинками на тегированные файлы, и любые операции с ней расценивать только как линкование/разлинкование, запретив копирование и удаление.

Ненуачо, ext4 уже создает служебную папку "/lost+found" со всяким говном с проверки, и никто туда даже не заглядывает, почему бы не сделать что-то более полезное. Заодно юниксвейно, все можно через файлы и сисколлы делать в файловых менеджерах.

@drq это, правда, может приводить к неочевидным приколам, которых от системы тегов не ожидаешь — нет простого способа полностью удалить файл, например. До тех пор, пока на него есть хотя бы один хардлинк, он будет храниться на диске. Потому что, насколько файловая система осведомлена, это полноценные файлы. Просто, по стечению обстоятельств, хранящие своё содержимое в одном и том же месте.

@n0icz

@dside Зато не надо ничего спецом индексировать в отдельном процессе.

Но да, проблема есть. Не то, что бы нерешаемая, наверное.

@n0icz

@drq для нужд каталогизации тебе нужна т. н. "слабая ссылка" (weak reference), которая не сдерживает зачистку исходного ресурса. Такие можно встретить в языках с managed heap и GC, и самое ходовое их применение — кэши.
В файловых системах симлинки к ним ближе всего. Но они могут вести вникуда. Их можно чистить автоматикой, но тогда получаем в её (автоматики) лице процесс, функционально неотличимый от индексатора, и ничего особенно не выиграли.

Я предполагаю, что многочисленные системы на внешнем индексаторе не просто так остановились.

@n0icz

@dside выкидывать недействительные ссылки при обращении к /tags?

Выигрыш тут в том, что не нужно опрашивать каждый файл в системе, а только тегированные. Что многократно меньше.

@n0icz

@drq это здорово раздувает операцию чтения уже проверкой действительности ссылок, а к тому же и допускает в ней запись. Это *можно* сделать, но в этом легко очень деструктивно накосячить. А для такого фундаментального элемента для функционирования системы… такое вызывает скорее опасения, чем восторг.

Но мы вроде в каком-то из прошлых тредов обсуждали, что можно ставить UX-эксперименты такого рода с FUSE. Тем более что каталогизировать таким образом файлы же наверняка нужно не по всей системе, а скорее в пределах домашней директории, и остальную инфраструктуру трогать необязательно.

Правда, драйвер такой ФС будет… отдельным процессом. Опять.

@n0icz

@dside так ФС и так способна на ходу опрашивать ссылки (например, в ls битые симлинки видно сразу), разве нет?

Fuse да, но fuse - это тормоза...

@n0icz

> так ФС и так способна на ходу допрашивать ссылки (например, в ls битые симлинки видно сразу), разве нет?

@drq я подозреваю, что это делает ls/шелл, а не ФС. Но это не точно.

Тормоза — смотря как напишешь. Ты в любом случае хочешь загрузить ФС дополнительной работой, так что быстрее оно быть не может. А если операции над этим деревом файлов производить планируется руками, там не такие высокие требования к скорости.

@n0icz

@drq глянул тут, и вижу что stat показывает число ссылок на inode, очень вероятно, что он где-то его хранит. Что логично — ему же надо как-то знать, когда удалён последний хардлинк и содержимое айноды можно больше не хранить. Теоретически можно этим воспользоваться, чтобы пропускать чистку ссылок, когда она не нужна. Иногда. Насколько это реально поможет… надо исследовать паттерны использования.

@n0icz