Replying to @⁨drq@mastodon.ml⁩

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

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

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

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

Replying to @⁨drq@mastodon.ml⁩

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

@n0icz

Replying to @⁨drq@mastodon.ml⁩

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

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

@n0icz

Replying to @⁨drq@mastodon.ml⁩

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

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

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

@n0icz

Replying to @⁨dside@mastodon.ml⁩

@dside нужно, потому что нафига делать оверлей там, где это необязательно, оверлеи всегда все затормаживают

@drq кстати для питона есть бинды к fuse, довольно неплохие если писать прототип :D
+ встроенный sqlite бекендом хранения

@n0icz

Replying to @⁨mo@mastodon.ml⁩

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

Это как, ща всратая аналогия будет, вводить внутривенно препарат на всю систему, чтобы воздействовать на отдельно взятый участок кожи. Избыточно, бессмысленно и часто даже опасно. Можно ведь намазать сам участок.

@n0icz

Replying to @⁨mo@mastodon.ml⁩

@mo в бета-версии этой аналогии не было слова "кожи", и уточнение, что так реально делают при химиотерапии, потому что там нету особого выбора, т. к. участок внутри. Но слово "кожи" устранило необходимость в этом :blobcatytriumphant:

У лимита символов встречаются полезные эффекты :blobcatlul:

@drq @n0icz