Какое хорошее решение для пометки файлов в Linux? [закрыто]

Я искал способ пометить мои файлы и искать / фильтровать их на основе этих тегов.

Вот мои ( обновленные ) требования:

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

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

Итак, у beagle огромные зависимости от gnome, и трекер в порядке, но есть некоторые зависимости, которые мне не нравятся ...

Занимался дополнительными исследованиями, и путь вполне мог бы быть расширенным атрибутом файла .
Это нативное решение для большинства современных файловых систем, но они пока не очень хорошо поддерживаются (большинство coreutils уничтожает их по умолчанию, например, для cp требуется флаг -a для их сохранения). Хотелось бы услышать некоторые мысли об их использовании, пока я сам пробую свои силы в хакерских атаках, хотя это может оправдать новый вопрос.

Не ясно, какой поиск вы хотите. Если вы хотите, чтобы он работал в любом месте в Unix, а не только в вашем домашнем каталоге, и вы хотите выполнять поиск только по путям, следующая схема работоспособна, с небольшим количеством хакерских атак и использованием стандарта locatedb:

1. Каждый каталог, который содержит хотя бы один файл с тегами, нуждается в стандартном подкаталоге, скажем .path-tags;
2. Каждый файл в каталоге $ FILE со ссылкой $ TAG (которая не должна содержать символ _) имеет ссылку$TAG_$FILE -> ../$FILE

Я оставляю детали locate-tagсценария вам; это должен быть двух- или locateтрехслойный файл , использующий только команду и хакерскую оболочку. (Если вам интересно, я мог бы написать один).

Некоторые главы KDE говорили о такой схеме метаданных, хотя я не помню деталей.

Также должна быть возможность делать более сложные, проверяющие контент тесты, основанные на этой схеме, с похожим сценарием find.

Мысли об обновленных требованиях

1. любой файл, читаемый пользователем, может быть помечен свободно - да, проблем не должно быть
2. пользователь может искать файлы, соответствующие одному или нескольким тегам - аналогично
3. файлы можно перемещать без потери ранее связанных тегов - каталоги, в которых они находятся, могут свободно перемещаться, но если файл перемещается из каталога, у нас возникают проблемы. Если теги приняли форму, $TAG_$INODE_$FILEи у нас есть эффективный способ определить, какие пути имеют данный индекс , тогда мы можем сделать это, теряя теги только в том случае, если мы выходим из файловых систем. Копирование файлов может создать некоторые проблемы, и это явно сложнее, чем мое первоначальное предложение.
4. резервное копирование системы может быть легко - не сложно.
5. нет зависимости от любой среды рабочего стола - нет
6. если задействован какой-либо графический интерфейс, должен быть запасной вариант - вот где мы живем!

Постскриптум Файл «обратный поиск по иноду», описанный ссылкой (2), которую вы показали мне в своем ответе (1), может быть использован для создания некоторой дополнительной инфраструктуры. Мы можем запустить службу в файле обратного просмотра, который проверяет, что каждый индекс, указанный в имени файла тега, совпадает с индексом файла (если есть), на который указывает тег. Если совпадений нет, то можно выполнить требуемую операцию (существует ли индекс по-прежнему? Где это?), И файл обратного просмотра либо мутировал, либо восстанавливался, а символические ссылки тега обновлялись.

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

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

http://www.tmsu.org/

любой файл, читаемый пользователем, может быть помечен свободно

Да.

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

Да. Либо с помощью инструмента командной строки, либо путем просмотра каталогов тегов в виртуальной файловой системе.

файлы могут быть перемещены без потери ранее связанных тегов

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

система может быть легко скопирована

Да. Это простой файл базы данных Sqlite 3.

нет зависимости от любой среды рабочего стола

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

если задействован какой-либо графический интерфейс, должен быть запасной вариант

Нет GUI в настоящее время.

Я думаю, что это может удовлетворить все ваши требования. В любом случае, это классный кусок кода:

http://pages.stern.nyu.edu/~marriaga/software/oyepa

GUI требует Qt, но есть приложение командной строки для поиска, и тот факт, что все теги на самом деле находятся в имени файла, упрощает манипулирование тегами | файлами из cli.

Никто не упоминал, но вам определенно стоит взглянуть на расширенные атрибуты файловой системы. Например, у ext4 они есть. Есть инструменты getfattr и setfattr для их работы. Конечно, вам придется написать несколько сценариев оболочки для поиска файлов, помеченных sometag. Относительно упомянутых вопросов все ответы - «Да». Вы должны только принять во внимание, что это зависит от файловой системы.

Удивил, что никто не упомянул TagSpaces . Он отвечает всем вашим требованиям, потому что теги хранятся в имени файла, а TagSpaces является кроссплатформенным.

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

В этой недавней статье об инструментах поиска рабочего стола Linux упоминается, что Tracker поддерживает тегирование. К сожалению, он должен быть наполовину сломан в старой версии, которую они тестировали. Может это сейчас исправлено?

1. Не для всей системы.
2. Вы можете поддержать это.
3. Это связано с Gnome.

Попробуй бигль . Я нахожу это довольно хорошо.

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

Некоторые другие альтернативы могут быть tagasistant , tagfs или dantalian .

Таким образом, вы не найдете интеграцию Nepomuk в gnome, в командной строке или где-либо еще в Linux.

И наоборот, с Tracker вы не найдете интеграцию kde AFAIK. Не уверен в CLI.

Так что, к сожалению, ответ «нет».

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

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

https://github.com/alvatar/dfym

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

TMSU

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

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

Удивлен, никто не упомянул об этом.

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

• Многие поддерживают тэгирование (конечно, подрывную деятельность).
• Многие кроссплатформенные; Windows, Mac, Linux, почти все Unixes.
• Многие из них имеют как графические интерфейсы, так и клиенты командной строки.
• У многих уже есть привязки для вашего любимого языка программирования / сценариев.
• Многие легко поддерживаются.
• Многие разработаны так, чтобы ими можно было легко обмениваться.
• Многие позволяют вам контролировать доступ.
• Вам не нужно заново изобретать колесо.
  • Вы изучаете и используете стандартные команды / инструменты, которые уже используются миллионами.
• Вы можете установить его сегодня для своего любимого репозитория ОС; apt-get install, yum install
• Вы также получаете управление версиями "бесплатно".

Пример Cli с Subversion: ~/svn/atestrepository: $ svn propset mytag "something" dir1 property 'mytag' set on 'dir1' $ svn propset myothertag "nothing" dir1/file1 property 'myothertag' set on 'dir1/file1' $ svn propset anemptytag "" dir1/file2 property 'anemptytag' set on 'dir1/file2'

$ svn propget -R mytag dir1 - something ~/svn/atestrepository: $ svn propget -R myothertag dir1/file1 - nothing $ svn propget -R anemptytag dir1/file2 - $ svn proplist dir1/file2 Properties on 'dir1/file2': anemptytag svn:keywords

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