Файловая система на основе тэгов

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

Ты тоже в курсе про HPFS и её расширенные атрибуты? :)

Возможно ли на уровне ФС (обозначенной архитектуры) делать выборки аналогичные тем, что в SQL? По удобству и по скорости?

Ну прикрути к обычной ФС тот же sqlite. Многое ли изменится? Да практически ничего, даже по размеру. Зато можно будет не только хранить расширенные метаданные, но и выполнять по ним выборку и какая бы скорость ни была, но это уже дополнительный механизм, не влияющий на скорость старого.

Ты тоже в курсе про HPFS и её расширенные атрибуты? :)

Да хоть xattr. Это всё не имеет смысла, пока нет индексируемой выборки.

А чем то, что ввели в макоси отличается от того, что давал непомук?

доказывать что любой сабж не нужен и обосновывать принципиальную невозможность нормальной реализации чего бы то ни было

ахах, главный принцип ЛОРа.

Ой, что то я запутался. Смотри, метаданные можно хранить в файле или в отдельной базе.

Если они хранятся в базе (некий расширенный фото каталогизатор) то можно легко делать произвольные выборки со всей мощностью sql. Но при этом мы легко видим массу узких мест и проблем.

Если они хранятся в файле то что бы их прочесть нужно либо прочесть часть файла (кстати, где хранятся mp3 теги?), либо данные из file allocation table. Пусть метаданные хранятся не в файле а в таблице размещения файлов (беготню по файлам по понятной причине не рассматриваем). Будет ли в таком случае работа с метаданными сравнима с работой с СУБД?

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

А чем то, что ввели в макоси отличается от того, что давал непомук?

Про то, как в MacOS сделали не знаю, но если по уму, то, как понимаю, атрибуты должны сохраняться при перенесении файла. Чего Непомук, вроде как, не умеет.

Плюс последний прибит гвоздями к конкретному DE, а не часть ОС.

метаданные можно хранить в файле или в отдельной базе.

Вообще-то, базы часто и есть отдельные файлы. Выше же придумали хорошую аналогию с хранением параметров в sqlite.

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

Это как пример самого простого варианта, реализуемого «на коленке». По хорошему, конечно, атрибуты должны храниться не в файле, а в параметрах самой ФС. И, конечно, единой сущностью, потому как потребуются произвольные выборки.

Автоматически окажутся ненужными:
— locate/mlocate/rlocate
— find станет работать не порядки быстрее
— каталогизаторам не понадобится сканировать файловые системы
— костыли, типа Непомуков или Биглов станут костылями

и т.п.

Сейчас этот функционал реально приходится реализовывать часто, но костыльно.

метаданные можно хранить в файле или в отдельной базе.

Вообще-то, базы часто и есть отдельные файлы.

Эээ, нет, я понял, я имел в виду в том же файле от которого метаданные. Всё своё ношу с собой. Метаданные в базе это как минимум проблемы синхронизации.

По хорошему, конечно, атрибуты должны храниться не в файле, а в параметрах самой ФС. И, конечно, единой сущностью, потому как потребуются произвольные выборки.

Единой сущностью, это значит у ФС есть отдельная единица в которой все метаданные от всех файлов? Это мало отличается от БД и имеет потенциальные проблемы.

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

Вообще, картину наверно можно сравнить с какой нибудь СУБД установленной на raw раздел. И если хранить в ней файлы то примерно так и выйдет. Только СУБД наверно надо как нибудь упростить, оптимизировать под простые запросы и большие блобы.

А чем то, что ввели в макоси отличается от того, что давал непомук?

Пока не знаю. Но подозреваю единым API и легкостью интеграции

Только СУБД наверно надо как нибудь упростить, оптимизировать под простые запросы и большие блобы.

И у тебя получится Be File System.

Эээ, нет, я понял, я имел в виду в том же файле от которого метаданные

Для тебя, наверное, будет удивительно, но «в том же файле» на уровне нынешних ФС нет даже имени и атрибутов :)

Метаданные в базе это как минимум проблемы синхронизации.

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

Единой сущностью, это значит у ФС есть отдельная единица в которой все метаданные от всех файлов? Это мало отличается от БД и имеет потенциальные проблемы.

Но именно так и построены все популярные ФС в последние лет 40.

МАКЕ ДИРЕЦТОРЫ?

иНЖАЛИД ДЕЖИЦЕ!
И жили ж люди без директорий...

Об удобстве спорить не будем, на вкус и цвет, как говорится. Твой кейс я понял, мой случай - жутко неудобно: мне тяжело ориентироваться в нескольких тысячах файлов, особенно если они разной категории: фотки, видео, документы, mp3...

И что делать, когда ты переименуешь файл или перекинешь на другой раздел?

Файлы? Какие файлы? У нас объекты, которые неважно где находятся. Разделы? Какие разделы? У нас одна большая помойка, которая тегами приводится в божеский вид.

Попробуй сейчас вывести в своей коллекции все фильмы, в которых снимался, скажем, Олег Янковский.

Сначала пришлось бы эти теги задать. А дать SELECT ... дело плёвое.

«в том же файле» на уровне нынешних ФС нет даже имени и атрибутов :)

Где сегодня хранятся теги mp3?

Метаданные в базе это как минимум проблемы синхронизации.

Остаётся только удивляться, как сегодня решается эта проблема в случае атрибутов файла

Кто нибудь использует на практике расширенные атрибуты?

Единой сущностью, это значит у ФС есть отдельная единица в которой все метаданные от всех файлов? Это мало отличается от БД и имеет потенциальные проблемы.

Но именно так и построены все популярные ФС в последние лет 40.

Строго говоря метаданные лежат не в одном месте а размазаны по накопителю. Это я и имел в виду, когда говорил что обегать метаданные или пройти по отдельной выделенной области. Хотя в принципе можно считать области метаданных (fat) за некие «файлы СУБД», по большому счёту разница не очень большая.

Не взлетело даже у MS...

Не, ну я понимаю, что флешки уступают место дропбоксу и иже с ним. Но выкидывать концепцию съёмного носителя пока рановато.

мне тяжело ориентироваться в нескольких тысячах файлов, особенно если они разной категории: фотки, видео, документы, mp3...

Ну и кто тебе мешает пользоваться одной категорией с фильтром, скажем, «видео»?

Файлы? Какие файлы? У нас объекты

Мы только что говорили про обычные ФС и доп. слой описания файлов. Будь внимательнее.

Сначала пришлось бы эти теги задать

Они у меня в коллекции итак заданы. Только через систему костылей из симлинков и при фиксированном положении/имени файла. А хочется без костылей и произвольно расширяемое.

«в том же файле» на уровне нынешних ФС нет даже имени и атрибутов :)

Где сегодня хранятся теги mp3?

Я про атрибуты и имя. Не выходи из контекста.

Кто нибудь использует на практике расширенные атрибуты?

До тех пор, пока по ним нет эффективной выборки — мало кто.

Строго говоря метаданные лежат не в одном месте а размазаны по накопителю.

Это уже технические мелочи, в контексте важно то, что они не находятся «в файле». И «с синхронизацией» проблем нет.

Аргументы не закончлись, только вот с тобой разговаривать надоело, потому что ты 2 раза подряд сказал чушь:

Файловая система на основе тэгов (комментарий) (жёсткие ссылки не спасут при перекидывании через разделы)

Файловая система на основе тэгов (комментарий) (речь была как раз о том, чтобы максимально автоматизировать и формализовать процесс)

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

Большинство твоих постов было про то, что всё и так уже есть, мол, пользуйтесь чем есть... Хотя никто не говорил, что всё надо переделывать, ТС даже заикнулся вроде про ссылки.

Где сегодня хранятся теги mp3?

Я про атрибуты и имя. Не выходи из контекста.

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

Кто нибудь использует на практике расширенные атрибуты?

До тех пор, пока по ним нет эффективной выборки — мало кто.

В общем это я как раз к тому, что сегодня эта задача решается чуть менее чем никак.

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

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

Файловая система на основе тэгов (комментарий) (жёсткие ссылки не спасут при перекидывании через разделы)

Разупорись, где в том посте было про перекидывание между разделами?

Файловая система на основе тэгов (комментарий) (речь была как раз о том, чтобы максимально автоматизировать и формализовать процесс)

Какой процесс и зачем для этого нужны вручную забиваемые теги?

Что говорит о том, что ты не разбираясь в теме даже не трудишься погуглить о том, что говоришь

Укурыш, я жёсткими и символическими ссылками каждый день пользуюсь, поэтому знаю о чём говорю.

Хотя никто не говорил, что всё надо переделывать, ТС даже заикнулся вроде про ссылки

У тебя проблемы с восприятием информации, обратись к специалисту.

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

В этой теме несколько веток с разными подтемами. Конкретно эта касалась способа хранения информации «вместе с файлами» или «отдельной сущностью». Напомню твою фразу:

Единой сущностью, это значит у ФС есть отдельная единица в которой все метаданные от всех файлов? Это мало отличается от БД и имеет потенциальные проблемы.

Так вот, сейчас итак «метаданные файла» в виде имени, пути, прав, времён и других атрибутов хранятся в «отдельной единице». И проблем особых нет.

А вообще, я всё же думаю что это не задача ФС.

Это задача именно ФС. Потому что теги в нашей гипотетической системе — это именно атрибуты файла. И перенося задачу на чьи-то ещё плечи мы создаём мало того, что дублирующую структуру, так ещё и имеющую трудности с поддержкой/обновлением/синхронизацией при работе с файлом вне этой системы.

Вот пришли к тебе твои приятели, Вася и Петя, и говорят тебе: «А вот ты нас всегда на попойках фоткаешь, давай, скопируй теперь мне фоточки со мной, а ему с ним».

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

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

Это ПО давно есть и всем доступно.

В противном случае - это как mp3-теги: у единиц заполнены и отсортированы, у большинства же как придётся.

Та же история, что с именами и путями файлов сегодня в текущем положении дел. У кого-то систематизированы, у кого-то — свалены в кучу. Это же не повод отказываться от путей и длинных имён?

Разупорись, где в том посте было про перекидывание между разделами?

Это частая задача. И попрошу без перехода на личности, я Вас нигде не оскорблял. Или это аргументы кончаются?

Разупорись, где в том посте было про перекидывание между разделами?
У тебя проблемы с восприятием информации, обратись к специалисту.

Всё понятно с Вами. Дальше продолжать смысла не вижу, Вы больше не имеет аргументации и перешли к оскорблениям.

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

А вот пикаса — стала.

Нет, давай лучше «директория».

Нет, давай лучше «директория».

Сейчас вроде не 1920 год.

Это частая задача

Об этой конкретной задаче я уже писал. При грамотном подходе к организации хранения данных описанная проблема некритична.

И попрошу без перехода на личности, я Вас нигде не оскорблял

Я тебя тоже. Или jeuta — твой виртуал?

Всё понятно с Вами. Дальше продолжать смысла не вижу, Вы больше не имеет аргументации и перешли к оскорблениям.

Вынужден заметить что у него окончание аргументации и переход на личности произошли раньше.

А вообще, я всё же думаю что это не задача ФС.

Это задача именно ФС

Я тут как раз кстати придумал пример, показывающий разницу между атрибутами как БД и настоящей БД.

Пусть у нас есть накопитель, на котором хранится некое видео. Пусть это будут к примеру кинофильмы. Конечно лицензионные. Что у нас будет храниться в тегах, хранящихся в атрибутах, хранящихся в ФС, в доме который построил джек? Название (чужой хищник против фреди крюгера 24), год выпуска, бюджет, жанр(ы), режиссёр, актёры, название серии фильмов к которой относится данный (чужой, хищник или фреди крюгер), и так далее. Вот мне очень понравился артист, который играл чужого хищника. Выразительный артист, и глубина игры трогает до слёз. Поэтому я поискал в каких фильмах он играл ещё. У меня таких было три. Тогда мне стало интересно, полная ли это его фильмография. И вот тут мы и приходим к этой разнице.

Может ли в нашей базе данных на атрибутах ФС храниться его полная фильмография? Нужно ли создавать пустые болванки файлов под фильмы, которых у меня здесь и сейчас пока нет? А может быть нужно создать файл для этого артиста? А что должно быть в этом файле? Может быть это должен быть текстовый файл, в котором должна лежать фильмография? Или не фильмография, или не только?

А может всё таки отдельная СУБД? Даже не приспособленная для хранения блобов, то есть вообще. Пусть блобы, то есть файлы, хранятся в каталоге $DB_DATA/storage/. Там может быть даже некая структура каталогов технического характера, например что нибудь типа как у кэша сквида. А в базе пусть хранятся указатели на соответствующий файл. Если он там такой конечно существует.

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

А здесь и в 2014 за употребление вендизма «папка» расстреливают.

Может ли в нашей базе данных на атрибутах ФС храниться его полная фильмография? Нужно ли создавать пустые болванки файлов под фильмы, которых у меня здесь и сейчас пока нет?

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

А здесь и в 2014 за употребление вендизма «папка» расстреливают

Илитка в треде? Мушку спили.

Может ли в нашей базе данных на атрибутах ФС храниться его полная фильмография?

Это другая сущность и другая история. От того, что в mp3-тегах у тебя хранится название исполнителя, у тебя же не появляется мысль хранить «mp3-пустышки» с дискографией?

Однако, если ты фанатеешь от исполнителя, то в нашей расширенной ФС у тебя может быть файл-ссылка на сайт исполнителя. И ты, сделав в ФС запрос по материалам можешь получить и ссылку на онлайн-документ. Ну, или даже на офлайн версию. И, безусловно, всякие фоточки, картинки альбомов и т.п.

Это всё и сейчас теоретически возможно на уровне внешних индексирующих систем. Но это крайне неудобно и костыльно, что и не позволяет развиться подходу. Даже куда менее удобно, чем descript.ion во времена 8.3-имён. Эти хотя бы поддерживались разными продуктами разных разработчиков.

И было бы особенно круто интегрировать локальную свалку с облачными сервисами

Да, это было бы круто. Вообще, переход от файлов через объекты к агентам. Без различий (с точки зрения потенциальных возможностей, конечно) между положениями в инфраструктуре — на компе агент находится, в телефоне или в облаке. Он просто есть и он тебе (и тем, кого ты к нему пустишь) доступен.

Но это намного более дальняя и сложная задача.

А вот DBFS практически сегодня реализуема без особых проблем. Увы, MS от неё ушла, вообще переориентировавшись на облака, Райзера посадили, больше на практике пока никто этим не занимается.

А, прошу прощения. Просто в процитированном была моя аргументация, так что подумал, что это ответ на моё сообщение.

А вот пикаса — стала.

Кстати, ещё очень важный момент в контексте DBFS. Сейчас распознавание лиц вводится и в Digikam. Только я оценить эффективность даже не смог. Потому что:
— Digikam хранит все данные в одной базе, что не позволяет работать с одним фотокаталогом с разных произвольных машин
— Digikam не синхронизирует каталог людей с каким-то контактным ресурсом, что не позволяет работать с каталогом знакомых единообразно в рамках разных систем.

А вот в Picasa всё это есть, что и склоняет выбор к ней практически без условий.

В рамках DBFS эти обе задачи могут единообразно решаться в рамках ФС. Если обеспечить ей интероперабельность через сеть. С метаданными фотографий — оно и понятно (пока решается костылём picasa.ini как во времена descript.ion). С контактами — интереснее. Сама суть DBFS создаёт возможность реализовывать системы, типа контактов (или календарей) прямо в рамках ФС, без лишних новых слоёв в виде программы-каталогизатора. Достаточно по каждому человеку создавать виртуальный файл, в метаданных которого использовать всю контактную информацию. Тот же vcard, но работа с которым может отсуществляться целиком средствами ФС.

Вообще, поразительный спектр возможностей открывается. Огромное число задач, которые ложатся сегодня на встроенные БД, типа sqlite, могут лечь сразу на ФС. Хоть хранение закладок или кеша в браузерах.

больше на практике пока никто этим не занимается.

Потому что на самом деле это тупик. Блобы (файлы) вторичны, информация первична. И, да, не нужно смешивать информацию и блобы. Ну, да, я понимаю что ты сейчас скажешь что блобы это же тоже информация, но думаю что на самом деле ты меня понимаешь.

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

Блобы (файлы) вторичны, информация первична.

Вот только реальные файлы уже очень давно не блобы. И содержат кучу связанной информации. Для каталогизации которой требуются костыли. Почему не озаботиться этой каталогизации у того, что итак с этими данными работает?

А когда информацию станет возможно организовывать правильной структурой

Вместо простого и эффективного решения ты предлагаешь несформулированную дополнительную сущность?

Вот только реальные файлы уже очень давно не блобы

К файлам лепят метаинформацию. С переменным успехом. Но основное содержание файла это именно бинарные данные: кодированные звук, изображение, видео. Да даже текст, на текущий момент это практически бинарные данные. Просто текст чуть легче обрабатывать для автоматического заполнения метаданных.

Собственно то, что в данном контексте называется метаданными, я и назвал бы информацией противопоставив бинарным дампам данных. С ними и надо работать. А блобы приложатся.

А когда информацию станет возможно организовывать правильной структурой

Вместо простого и эффективного решения

Я не о том. Не важна технология. Когда ты оформишь данные правильной структурой, они заработают на новом уровне. Ну считай что к тому уровню, который мы сейчас называем метаданными, сделать ещё один уровень метаданных.

С переменным успехом. Но основное содержание файла это именно бинарные данные

— Наши теги не имеют отношения к содержимому файла. Это такие же атрибуты, как имя, путь, права доступа или дата создания. И хранить их надо таким образом.

— Ради того, чтобы решить отсутствие упомянутой возможности в «именно бинарные файлы» суют костыли в виде разнокалиберных встраиваемых мета-данных, от id3 у музыки до xmp у картинок.

Я не о том. Не важна технология. Когда ты оформишь данные правильной структурой, они заработают на новом уровне.

Я пока за этими словами не вижу сути. Попробуй формализовать то, о чём ты говоришь.

Ну считай что к тому уровню, который мы сейчас называем метаданными, сделать ещё один уровень метаданных.

Ну так это и будет наша DBFS, о которой идёт речь.

Ну и кто тебе мешает пользоваться одной категорией с фильтром, скажем, «видео»?

Если если я укажу все необходимые фильтры/категории/теги, то их количество будет примерно равно глубине дерева подкаталогов. Получаем то же самое.

Получаем то же самое.

Именно. На том уровне, как мы используем ФС сегодня, при работе с DBFS ничего не изменится. Просто появляются _дополнительные_ сущности. Как в своё время при введении длинных имён и атрибутов ничего не изменилось в плане работы с короткими именами.

Зато также, как и тогда, отпадёт надобность в ряде костылей. И появится намного больше возможностей.