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

@n0icz

@dside заодно этот же процесс может в фоне шебуршить очисткой понемногу. Или даже проверять в момент обращения

по сути получится как /proc, только /tag :р

@drq @n0icz

@dside впрочем, конечно бывают и более серьезные степени распространения, для которых это может понадобиться... наверное поэтому таблетки формально рецептурные, а крем — нет

@drq @n0icz

@drq кстати о xattr и freedesktop:
> user.xdg.tags is not part of the official standard, but it has become a "de facto" standard as several popular programs have implemented support for it
src: https://wiki.archlinux.org/title/Extended_attributes#User_extended_attributes

@mo @n0icz

@drq
Я не очень понял, ты хочешь чтобы, условно, в файловом менеджере можно было создать группу файлов и находить эти файлы в отдельной вкладке, а не настоящей папке? Ну тогда удобнее будут симлинки, если честно. Да и проще будет реализовать на уровне файлового менеджера. Типа в домашней директории создать папку groups в ней папки групп, а в каждую такую папку кидать симлинки на избранные файлы.

@n0icz

@volandevsrat
1) тогда каждый менеджер будет это реализовывать по-разному, и будет жопа
2) а че если я в шелле вообще сижу?

@n0icz

@drq
1) по итогу просто победит самая распространенная реализация. Да и к тому же, это реально не удобно, только если пользоваться сразу несколькими менеджерами.
2) ну открывать просто по пути к симлинку. Ну или просто написать консольную утилиту.

Ну и вообще, давайте не будем нагружать файловую систему лишними задачами. Не хватало ещё багов в функциях ФС
@n0icz

@volandevsrat почему это, "лишними"? Функция ФС - организовывать дискретные фрагменты данных в человекопонятном виде. Теги - метод организации. В чем проблема.

@n0icz

@drq
Так ты назвал не функцию, а задачу
А теги это уже отдельная функция. А как известно, чем больше функций, тем больше и ̶о̶т̶в̶е̶т̶с̶т̶в̶е̶н̶н̶о̶с̶т̶ь̶ потенциальных багов. Я не хочу потенциальных багов на уровне файловой системы. Уж лучше обойтись файловым менеджером и консольной утилитой
@n0icz

@volandevsrat ну да, давайте вообще перестанем че-то новое изобретать, у нас же конец истории.

@n0icz

@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

@dside inode это ж уже про хардлинки. А они сильные ссылки

@drq @n0icz

@mo это про предложение выше по треду: https://mastodon.ml/@drq/117004134401319055

Чистка так-то потребуется и тем, и другим. У симлинка просто последствий неуборки немножко меньше.

@drq @n0icz

@drq если fuse система будет содержать только симлинки, то реальные файлы будут читаться с нормальной фс

@dside @n0icz

@mo @drq ну, кстати, да, в FUSE можно держать только инфраструктуру тегов, а исходные файлы пусть существуют как есть, ничего не ломая.

@n0icz

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

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

@n0icz

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

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

@n0icz

@dside ну хз насчёт внутривенно, но ацикловир бывает в таблетках...и да, мне это тоже казалось странным, хотя он конечно и полностью безвреден

@drq @n0icz

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

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

@drq @n0icz

@dside это где у тебя лимит в 500 символов...?

@drq @n0icz

@mo 1000, 1000. Там несколько факторов столкнулось: бета-версия была длиннее, плюс был ещё один абзац, и когда символы закончились, я начал сокращать. И сокращение пошло даже слишком хорошо.

@drq @n0icz

@dside

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

А как это мешает тому, что уже есть в системе? Никто ж не заставляет этой фичей пользоваться, но если надо - вот она есть.

@mo @n0icz

@drq дело не в фиче, а в том, где она находится. Ты же её прямо в ФС предлагаешь затолкать. Если мы считаем фичу опасной, надо либо очень мощно вложиться в её тестирование, либо поднять её от фундамента повыше. Вот решение с FUSE — как раз последнее.

@mo @n0icz

@dside А я что предлагаю ее не тестировать, что-ли?

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

А не просто очередная с-боку-реализация, которых, в общем-то и так полно, и которые все разные, и не везде есть.

@mo @n0icz

> А я что предлагаю ее не тестировать, что-ли?

@drq а я где-то говорил, что предлагаешь? Дело не в том, что это надо делать. А в том, что это надо не просто делать, а в *конских* объёмах. Такие объёмы оправдать получится только какими-то очень существенными выгодами.

А для того, чтобы на этом можно было строить пользовательский опыт в DEшках, надо не спускать как можно ниже в абстракциях, а банально добиться популярности. Спуск на уровень ниже теоретически даст много установок, что может быть *последствием* популярности, но необязательно ей *предшествует* – т. е. кучей установок ты ещё не гарантируешь уровня популярности, могущего спровоцировать повальную интеграцию. Следствие в обратную сторону крч.

Интеграция чего-то "сбоку" не обрекает на нишевость. Пример – иксы.

@mo @n0icz

@dside Ну или нам нужен стандарт freedesktop для таких вещей, потому что разброд и шатание достали.

Все еще непонятно, что делать, правда, если у тебя командная строка, но тегов все равно хочется.

@mo @n0icz

@drq freedesktop звучит как более подходящий уровень, да. Хотя и им потребуется UX research, чтобы выдвигать стандарт, который сможет быть чем-то кроме документа. И прототип на FUSE, теоретически, поможет собрать вишлист, приближенный к боевому. Хотя это не единственный способ, конечно.

Мне ещё понравился приём с атрибутами (xattr) в макоси, где можно хранить первичные данные, а строить из них представление уже в интерфейсных обёртках – где банальным внешним индексером, где FUSE'ом. Формат данных выглядел несколько всрато, но может у него есть не очевидные мне преимущества.

@mo @n0icz

@dside то есть по сути...у нас *уже* есть теги на уровне фс??

@drq @n0icz

@mo да и нет. Сами теги есть, но это только кусочек того, что интересует @drq (и @n0icz?), ещё вьюху/индекс/каталог по по ним нужно.

Грубо говоря, есть бэкенд/БД, фронтенда/интерфейса нет.

@drq Если принять во внимание, что фс больше чем одна, все становится несколько забавнее: сейчаc, как минимум на средней по больнице машине, раздел uefi находится под fat. Нередко что-то да живет на сетевых: smb, nfs. И если вспомнить, что еще и на флешках-дисках-смартах-плеерах может оказаться -- и с хардлинками, да и софтлинками становится несколько грустно.
Получить еще одну прослойку: заманчиво конечно, но почему-то не очень хочется, при имеющихся внешних индексаторах или тех же xattr.

Вспоминается про ntfs с ее потоками файла: насколько прикольная вещь хранить с основным файлом еще чего-то. оно даже прозрачно использовалось для метки внешнего файла или локального. Но с настолько неудобным и сакральным способом использования, что диву даешься. Либо удалили, либо собирались удалять в Win11 -- ну и ладно, пользователь не сильно заметил.
Вопрос востребованности и, соответственно, поддержки всего этого.

@dside @mo @n0icz

@drq @n0icz это вроде файловые менеджеры умеют. Теги можно хранить в атрибутах файла и сейчас, наверное там и хранят.

@3draven ...Каждый по-своему и несовместимо друг с другом, что привязывает меня к конкретному файловому менеджеру, что меня нисколько не устраивает.
@n0icz

@drq @n0icz привязаться к конкретной фс судя по всему чем-то лучше. Если ехать, то уже решено, если шашечки, то тут дело вкуса.

@3draven ФС меняются гораздо реже, чем инструменты работы с ними.

@n0icz