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

Практичней. Но эффективней именно держать метаданные в отдельной СУБД. Другой вопрос, что, как тут уже выше отметили, заполнять-то их кто будет?

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

Да, и это тоже.

хочется чем-то исследовательским заниматься, душа лежит к этому (за денюжку, естественно), но найти, куда усилия приложить, не получается :(( В РФ так вообще кроме Samsung'а и ещё ряда фирм с укомплектованным штатом не знаю никого.

А как же Завалишин с его «Фантомом»? У меня, правда, создалось впечатление, что «Фантомом» они занимаются в свободное от заказной разработки время, и отдельные люди им на эту тематику вряд ли нужны...

Вообще они зачастую заполнены. Где-нибудь в интернете, например, на musicbrainz/lastfm/imdb/whatever. Только интегрировать ФС с этим сегодня никто в здравом уме не будет.

А как же Завалишин с его «Фантомом»? У меня, правда, создалось впечатление, что «Фантомом» они занимаются в свободное от заказной разработки время, и отдельные люди им на эту тематику вряд ли нужны...

Ты его знаешь? Если да — познакомь меня с ним.

Ты его знаешь?

Знал бы - возможно, уже работал бы там. :)

Пошарься на dz.ru в разделе контактов. Вдруг случится чудо?

Подробнее про Фантом...

Ключевое слово: music. Теги в mp3 имеют большую историю и действительно часто частично заполнены. Насколько хорошо, правда...

8-) гы-гы.
шутишь? яж его не знаю! Но таки вспомнил кто это!

http://www.youtube.com/user/iwalker2000

http://blogs.technet.com/b/iwalker/

Без директорий бардак получится. Но в чем-то ты прав: метаинформации в ФС ой как не хватает.

Кластер уже прикупил для этого? :}

Сомнительно, что с такой задачей справится первый из топ500 суперкомпьютеров.

«Папка» как-то не очень, лучше «директория».

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

Одна проблема: как по inode получить список всех имён этого файла, чтобы, например, удалить его или посмотреть список всех «тегов»? Костыляторов, которые эмулировали тэги хардлинками, полно, но эффективного решения этой проблемы не видел.

Я как вспомню, как подвисает ФМ при отображении /usr/lib, так сразу и понимаю, что тысячи файлов в коренном каталоге - это быстро.

А зачем тебе теги именами отображать? Для тегов отдельного слоя совместимости хватит, рядом со слоем совместимости с POSIX.

Открываешь файловый менеджер, там абсолютно все файлы, что есть на дисках

Жди в следующих версиях гнома, папки это слишком сложно для пользователя правда тегов тоже не будет, так как это тоже слишком сложнл

Для тегов отдельного слоя совместимости хватит, рядом со слоем совместимости с POSIX.

Насколько я понял ТСа, он хочет отказаться от того, что даёт POSIX.

Хотеть - не вредно. Все его хотелки лежат в слое абстракции. Реализовать его можно рядом с POSIX и на текущих файловых системах.

mkdir — make direktory, поэтому директория — это труъ.

Хотя, по сути, название содержание не меняет.

Открываешь файловый менеджер, там абсолютно все файлы, что есть на дисках

Через месяц откроется или ещё нет?

тэг «фотографии»
Или там «документы»

А скан моего паспорта.jpg — это документ или фотография?

Дальше можно фильтровать по дате, по заданным пользовательским тэгам (например, город, или какой-то человек)
по заданным пользовательским тэгам

Что проще — лепить к каждой фотографии теги или свалить все эти DSC666 и Photo100500 в одну уютную папочку?

никакого бардака
иерархической структуры нет вообще

/0. Не взлетит.

direktory

Fail.

make directory

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

Но в чем-то ты прав: метаинформации в ФС ой как не хватает

А тем временем потоки в NTFS существуют уже 20 лет.

Преимущества очевидны

преимущества для пользователя. программировать под такую фс - удовольствие не из самых приятных

Через месяц откроется или ещё нет?

Никто ж не говорит отрисовать всё сразу. Отрисовывать по мере прокрутки.

А скан моего паспорта.jpg — это документ или фотография?

И то, и другое, если хочешь.

Что проще — лепить к каждой фотографии теги или свалить все эти DSC666 и Photo100500 в одну уютную папочку?

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

FUSE тебе в руки.

Никто ж не говорит отрисовать всё сразу

Чтобы что-то нарисовать, нужно сначала что-то получить, обработать и упорядочить (например, по дате, как указал ТС).

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

Тогда чем это лучше уже существующей иерархической концепции? Вот практический пример: я беру фотоаппарат, подключаю его к компьютеру и перемещаю фоточки с именами вида DSC12345.JPG в папку с именем, например, „Пьянка”. Как аналогичная процедура будет выглядеть в случае ФС, построенной полностью на тегах?

А скан моего паспорта.jpg — это документ или фотография?

В том-то и дело, что это И документ, И изображение (фотографией не назвать), И скан - присутствует в этих трех списках

Что проще — лепить к каждой фотографии теги или свалить все эти DSC666 и Photo100500 в одну уютную папочку?

Проще при загрузке с фотоаппарата указать, что это - фотографии с шашлыков 2013 года

Я тоже об этом думал. Кстати, можно реализовать при помощи ссылок

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

И документ, И изображение (фотографией не назвать), И скан

А кто будет забивать все эти теги? Пользователь? Он может добавить два тега — „изображение” и „скан”, а потом забыть и безуспешно искать его среди документов. К тому же ему нужно задавать и помнить как можно больше тегов, иначе потом он среди гор всего остального мусора никогда ничего нужного не найдёт.

Проще при загрузке с фотоаппарата указать, что это - фотографии с шашлыков 2013 года

Это указывается в момент создания папочки „Фотографии с шашлыков 2013 года”.

в мак оси теперь есть это

А теперь после этого выбери фотографии 2013 года, на которых есть я или моя мама

Опечатался, поздно уже, голова плохо варит.

Чтобы что-то нарисовать, нужно сначала что-то получить, обработать и упорядочить (например, по дате, как указал ТС).

Когда файлов слишком много для сортировки, достаточно предлагать пользователю сразу тэги на выбор (и тэг «неотсортированное», конечно, если файл вообще никак не помечен, что вряд ли возможно, потому что тип файла — тоже тэг, по сути).

Тогда чем это лучше уже существующей иерархической концепции? Вот практический пример: я беру фотоаппарат, подключаю его к компьютеру и перемещаю фоточки с именами вида DSC12345.JPG в папку с именем, например, „Пьянка”. Как аналогичная процедура будет выглядеть в случае ФС, построенной полностью на тегах?

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

А теперь после этого выбери фотографии 2013 года, на которых есть я или моя мама

Это оторванный от реальности юзкейс. На практике в 99% случаев людей интересует набор фотографий, сделанных в конкретном месте и в конкретное время, например, „пьянка на днюхе у Васи 2014” или „отпуск 2013 в Зажопинске”. К тому же данная задача практически не решаема даже в случае тегированной ФС: пользователь скорее пошлёт всё лесом чем будет сидеть и задавать каждой из 100500 фотографий адекватные теги.

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

Лучше бы этим все занимались, а не велосипедили всякие системд, вяленые и миры.

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

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

и тэг «неотсортированное», конечно

От создателей „Новая папка” и „Новая папка 2”?

Только автоматически у фоток в тэгах будут ещё год, месяц, дата

Для поиска по дате теги не нужны. К тому же у фотоаппаратов часто бывает сбитое время, поэтому все фотографии могут оказаться с тегом „2001 год”. Поиск по дате вручную созданного каталога в этом случае имеет больше шансов на успех.

место

Место можно отразить в имени каталога, опять теги не особо нужны.

люди

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

не создавая отдельного альбома(каталога) с копиями фоток

А это и сейчас можно с помощью жёстких/символических ссылок. Только и в случае с тегами, и со ссылками это придётся делать вручную, поэтому есть ли разница?

Выбираешь тэг «фотографии», остаются только фотографии, все, что есть на диске

Это работает пока у тебя мало файлов. Вот когда тебе выдаст ~20к фотографий одним списком... В общем не очень юзабельно.

Ты хочешь структурировать данные.
Это не задача файловой системы.

Как быстро забылось дело Рейзера.

Есть. Если захочешь переименовать каталог с фотками или саму фотку, то всё порушится. Это одна из проблем, которые ТС и сочувствующие хотят решить вроде бы.

Это работает пока у тебя мало файлов. Вот когда тебе выдаст ~20к фотографий одним списком

Когда я Пикасу запускаю, она по дефолту выдаёт сразу все мои 53 тыс. фоточек. И не чихнёт. Раньше также и F-Spot работал, пока жив был. Так что не вопрос совсем :)

Если захочешь переименовать каталог с фотками или саму фотку, то всё порушится

С жёсткими ссылками не порушится.

А теперь после этого выбери фотографии 2013 года, на которых есть я или моя мама

С «или» пока плохо. С «и» такое есть в Пикасе.

Вот для иллюстрации все фотки, где есть одновременно я, жена и дочка :)

Но это частный случай, конечно. Из-за отсутствия теговой функциональности в ФС, работает только внутри конкретной программы.

С жёсткими ссылками не порушится.

Как оставить жёсткую ссылку при переносе файла на другой раздел?

А тем временем потоки в NTFS существуют уже 20 лет.

Мало хранить данные. Нужно ещё выполнять по ним быструю выборку.

Идея нормальная, но кто будет ставить теги? Пользователь ручками? Мне, как пользователю, лень

- В значительной мере автоматизируется.
- Не лень для того, что реально нужно.
- Важно сохранить возможность оставлять теги при передаче файла. Тогда один раз прописав их, можно распространять уже оформленный файл.

Кому-то лень и называть файлы развёрнутыми именами, это же не повод отказываться от длинных имён и возвращаться к нормам MS-DOS/TR-DOS/CP/M/ORDOS...

Как оставить жёсткую ссылку при переносе файла на другой раздел?

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

но совсем не повод пилить с нуля принципиально новую концепцию ФС без обратной совместимости.

Вот из-за такого подхода до сих пор и жопа с ФС.

Мало хранить данные. Нужно ещё выполнять по ним быструю выборку.

Если абсолютно все файлы будут протегированы — поиск по тегах будет не быстрее обычного поиска по именам.