Комментарии 19
А вы точно хорошо искали? Прямо сейчас я вижу в поиске не меньше полудюжины названий, например, здесь. Самые старые из нулевых, самые свежие — годичной давности. Неужели они все не подходят?
Та, которой мне приходилось пользоваться, распространялась в виде одного .jar файла без всяких модулей ядра и работала от простого пользователя.
Выглядит так, что из того что там упомянуто, только tmsu подаёт признаки жизни
Видимо, всё-таки ДОСТАТОЧНО хорошо искал. Посмотрел пару решений, и обнаружились тонкости. Далее на примере TMSU. Получить список файлов можно двумя способами:
по одному тэгу: т.е. всего один критерий. Очевидно, что этот способ не подходит;
заранее сделать запрос на объединение тэгов и получить список фалов. Ключевой момент - ЗАРАНЕЕ. Пример с сайта:
$ ls mp/queries
README.md
$ mkdir "mp/queries/mp3 and not folk"
$ ls "mp/queries/mp3 and not folk"
summer.1.mp3
winter.3.mp3т.е. у вас не будет возможности при открытии файла в проигрывателе выбрать комбинацию тэгов "здесь-и-сейчас". И это плохо-плохо.
От себя добавлю, что создание запроса "заранее" - оно очень сильно облегчает реализацию всей файловой системы. Ключевой момент здесь в том, что количество этих запросов известно и оно небольшое, явно меньше всех комбинаций тэгов.
у вас не будет возможности при открытии файла в проигрывателе выбрать комбинацию тэгов "здесь-и-сейчас"
Справедливости ради, очень многие (если не все) диалоги открытия файлов поддерживают создание директорий. Поэтому чаще всего их не обязательно создавать заранее - можно прямо в диалоге выбора файлов.
Я поискал за вас.
TSMU:
$ ls mp/tags
big-jazz mp3 music
$ ls -l mp/tags/music
drwxr-xr-x 0 paul paul 0 2012-04-13 20:00 big-jazz
drwxr-xr-x 0 paul paul 0 2012-04-13 20:00 mp3Судя по всему произвольные комбинации тегов вполне поддерживаются.
Tagsistant: прямо написано, что поддерживается:
You can even combine the results of more than one query by placing a +/ in between, like in startrek/+/starwars/ which merges the files tagged startrek with the files tagged starwars.
You cd to /path/to/mountpoint/tags/video/HD/thriller/sci-fi/@ (the order isn't important) and copy your file there.
/tag0/tag1 (starting at the tagfs root) retrieves all files that are marked with both tag0 and tag1. Prepending a '-' negates a tag, selecting every file that is not marked with the tag.
А чем хардлинки с много-много каталогов не устроили?
Расскажите подробнее, что вы имеете в виду.
Если на каждый тег делать по каталогу, и внутри них каталоги с остальными тегами и так далее, то получится экспоненциальная вложенность. Не уверен, насколько это будет удобно и быстро работать.
Кроме того, при люьой структуре папок с хардлинками, для удаления файла придется пройти и отдельно удалить его из всех каталогов, куда он может быть слинкован. Тоже не уверен, насколько это удобно и быстро.
У меня 2-4 уровня вложенности получается.
Фильмы:
Документальное
....
.....
Образовательное
Физика
Биология
....
.....
и т.д.
С ситуацией тотального удаления не сталкивался, это обычно бывает когда появляется версия с лучшим качеством.
Хардлинки работают в пределах одного диска/файловой системы;
Все операции с каталогами (например, создать много-много вложенных каталогов с дубликатами) - это работа внешнего скрипта. Немного не удобно;
Операции с файлам (раскладывание по каталогам и удаление) - тоже скрипт. Файловыми операциями копирования/удаления обойтись не удастся;
Заполнение файлами "отрицательных" каталогов (не-Физика) - по-моему это будет Боль.
Почему вы решили реализовать именно модуль ядра, вместо использования FUSE?
Это решение было скорее перестраховкой на всякий случай, так как выяснились моменты, например:
вложенность тэгов сразу приводит к динамической генерации путей. И количество всевозможных вариантов таких путей явно превышает возможности компьютера. Например, количество комбинации для 21 тэга (даже без учёта "не-" тэгов) уже больше максимального 64-битного числа. Т.е. никакие фиксированные inode вас не спасут;
операции с добавлением и удалением файлов в тэгах меняют содержимое в других тэгах. Например, если фильм удалить из папки детектив/фантастика/ужасы, то он сразу же удалится в папках детектив/ужасы; детектив/ужасы/фантастика и появится в детектив/фантастика/не-ужасы; детектив/не-ужасы ну и так далее. Очевидно, что сам линукс содержимое папок где-то у себя кэширует. Вот только непонятно было, к каким возможностям доступ дадут, к каким ограничат.
Вполне возможно, что программы уровня пользователя (например, тот же fuse) всё это и так поддерживает. Но решил использовать вариант с максимальным доступом к внутренностям файловой системы, кэшам, структурам. В общем, перестраховался.
А xattr не подходит?
Можно по-подробнее, а чем он может подойти? Видеопроигрыватель сможет отфильтровать по нему файлы? Или это способ хранения информации?
Технически подходит, практически - сильно много возни:
- надо специально включать при монтровании
- нельзя так просто взять перенести xattr с одной FS на другую
- или в архив
- о переименовании тегов вообще отельный цирк с конями
В общем можно, но только теоретически
Вы переизобрели semantic web.
Кстати, в KDE 3 планировалось нечто подобное, а даже работало в beta. Не взлетело.
В Windows тоже пытались (кажется WinFS должно было называться). Аналогично.
Но реализация неплохая, да.
Хотя модуль ядра действительно перебор. FUSE было бы достаточно.
Замешиваем файлы в тэги. Часть 1