LINUX.ORG.RU

Расширенные аттрибуты файлов; их использование для упорядочивания и поиска файлов


0

1

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

Ну, file capabilities, ACL… А вот более приближенное к простому конечному пользователю использованию?

Есть вот какие-то рекомендации от freedesktop. А реализации удобные есть или нет?

Меня, собственно, интересует реализация поиска файлов по тегам. Есть, конечно, nepomuk или tracker. Но ужь очень они, по слухам, тяжеловесные и привязанные к своим окружениям. Меня больше интересуют программки, чем-то похожие на mlocate. Раз в сутки обновляется база тэгов, команда для поиска файлов по тэгам. Есть ли такие программки? Если такие программы не нужны, объясните почему.

★★★★★

Если такие программы не нужны, объясните почему

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

no-dashi ★★★★★
()

С расширенными аттрибутами сейчас такая беда: если ты скопируешь файлик - они потеряются. Скопировать с аттрибутами ты можешь только с помощью cp с ключем --preserve=xattr , еще rsync умеет. Вобщем забудь про Midnight Commander, Konqueror, Nautilus... Как по мне - это самая большая беда.

Вот мой feature request для MC - если там можно его как-то поднять - подсобите:
https://www.midnight-commander.org/ticket/2468

Что касается поиска. find не умеет. Но inotify умеет, так что можно самому навоять каталогизатор.

Что касается nepomuk и beagle - согласен, монстры.

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

Kroz ★★★★★
()
Ответ на: комментарий от no-dashi

про «очень медленно» как-то не верится. вот mlocate у мну работает с полумиллионом файлов, и ничего, как-то не тормозит.

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

anarquista ★★★★★
() автор топика
Ответ на: комментарий от anarquista

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

Да ну? Итак, во-первых, у mlocate (внимание!) ЕСТЬ СВОЯ БАЗА МЕТАДАННЫХ (имен и путей) ОБНОВЛЯЕМАЯ ПО ШЕДУЛЕРУ. Опа. Без этой базы mlocate превращается в find, назвать которы «быстрым» язык не поворачивается. Во-вторых, база mlocate содержит только пути и имена, в то время как база метаданных должна содержать еще и «тэги», размеры, даты модификации, количество ссылок, указания дублированности. Ах да - и забыли самое главное - индексирование контента документов.

no-dashi ★★★★★
()

метаданные, ой

cp ~/фоточки /media/флешечка

geekless ★★
()
Ответ на: комментарий от anarquista

В графических файловых менеджерах же используются gvfs-атрибуты… Виртуальные.

So what?

Kroz ★★★★★
()
Ответ на: комментарий от sin_a

Метаданные нужно хранить отдельно от данных.

Дык они так и хранятся - в отдельных структурах файловой системы.

Kroz ★★★★★
()
Ответ на: комментарий от no-dashi

Это я хорошо понимаю. Ну так, раз в сутки обновлять базу, искать по тегу, почему нет? Для редко изменяемых данных почему нет?

Другое дело, что при обновлении базы mlocate легко определить, изменилось название файла или нет. Достаточно лишь пройтись по директориям и смотреть на время модификации. С атрибутами такое, увы, не прокатывает: изменение атрибутов файла никак не отражается в директории (?).

anarquista ★★★★★
() автор топика
Ответ на: комментарий от Kroz

FM не нужен, очевидно жеж.

лично я пользуюсь в основном к вендо-шаре слазить.

mumpster ★★★★★
()
Ответ на: комментарий от Kroz

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

Fxd.

sin_a ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.