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

71

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

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

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

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


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

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

жюльен
источник
2
Проблемы с расширенными атрибутами файлов: (i) По моему опыту, они мешают, когда вы хотите сделать резервную копию. (ii) Вы не можете использовать их при перемещении между файловыми системами. Кроме того, они были бы правильной вещью.
Чарльз Стюарт
PytagsFS superuser.com/a/89140/129520
n611x007
На форумах PC-BSD со ссылкой на выпуск этого вопроса 2010 года: PC-BSD, расширенные атрибуты и тегирование; OpenMeta и подход Apple
Грэм Перрин
1
Неудивительно, что Reddit имеет гораздо лучшие и новые ответы на этот вопрос .
Дан Даскалеску

Ответы:

13

Не ясно, какой поиск вы хотите. Если вы хотите, чтобы он работал в любом месте в 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 ...

Чарльз Стюарт
источник
1
Это хорошо, и я тоже думал об использовании символических ссылок. Проблема в том, что файл не может быть перемещен без потери его тегов. В идеале теги должны быть независимыми от пути, и поиск тега должен возвращать реальный файл, а не мертвую символическую ссылку ... PS: я все для решения на основе оболочки, но я думаю, что проблемная область делает его таким, чтобы он было бы довольно больно поддерживать только с помощью сценариев оболочки, я надеюсь, что кто-то докажет, что я не прав
julien
Я отредактировал свой вопрос, чтобы (надеюсь) прояснить, какое решение я ищу. ура
Жюльен
Черт, я никогда не понимал, что inode, где есть постоянные направляющие для файлов, это пища для размышлений!
Жюльен
1
Иноды - это uids, но они привязаны к заданному fs, поэтому они не являются guids. Это неплохая вещь, поскольку копирование, резервное копирование, архивирование и т. Д. Означают, что файлы дублируются и хранятся в других файлах, и вы хотите, чтобы состояние fs давало вам достаточно информации, чтобы распутать результаты.
Чарльз Стюарт
1
Я пропустил изюминку, какое программное обеспечение может вместить это? Я надеялся на то, что смогу использовать случайно, не написав свою собственную инфраструктуру. (Но ясно, что я могу сам при желании
расширить его
22

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

http://www.tmsu.org/

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

Да.

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

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

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

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

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

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

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

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

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

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

Пол Руане
источник
Выглядит очень интересно. Есть ли у вас какие-либо идеи, как реализовать возможность перемещения файлов без потери связанных тегов?
студент
@student: в настоящее время есть команда 'repair', которая работает с перемещенными и измененными файлами. (Однако, если вы оба переместите и измените файл, это не будет обнаружено.)
Пол Руане
Возможно, можно написать варианты mv, cpи rmкоторые также обрабатывают ваши теги (назовите их, например tmv, tcpи trm), тогда вы не потеряете теги, по крайней мере, если будете использовать командную строку для перемещения файлов ...
студент
@student TMSU теперь включает в себя несколько сценариев , которые выполняют операции с файловой системой в то время как сохранение базы данных в актуальном состоянии : tmsu-fs-mv, tmsu-fs-rmи tmsu-fs-merge.
Пол Руане
Извините за мой вопрос, но ... почему бы просто не клонировать теги при автоматическом перемещении файла? Нужно ли вручную обновлять файлы при перемещении?
erm3nda
6

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

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

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

laramichaels
источник
1
Со страницы: «Информация тегов хранится в имени файла» - так как же выглядят отмеченные имена файлов? Кстати, ссылки на этой странице очень интересные: +1.
Чарльз Стюарт
отчет для счета [материал работы, час, произведенный мной] .odt
laramichaels
@laramichaels Я знаю, что это довольно старый, но я нашел подход очень заинтересованным. Если бы не отсутствие документации (нигде там не объясняется, как работает именование файлов), я бы принял это. Если у вас есть какие-либо новости о таких инструментах, пожалуйста, дайте мне знать,
TomCho
6

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

Алик
источник
Inode-данные файла должны быть определенно правильным способом сделать это на ext4 fs, но не обеспечат обратной совместимости. Правильно?
erm3nda
6

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

TagSpaces

Дан Дакалеску
источник
1
пространства тегов не имеют запасного CLI, поэтому он не отвечает всем требованиям. Или у него есть CLI? Если да, пожалуйста, дайте мне знать!
TomCho
В Debian 9 apt поддержка приложения отсутствует. Что-нибудь идет? - - Вы можете установить приложение на эти инструкции tagspaces.org/products
Léo Леопольд Hertz 준영
Можете ли вы сравнить ваше предложение с Linux Desktop Search Tools?
Лео Леопольд Герц 준영
5

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


источник
1
да, я надеялся найти альтернативу этому, но это не выглядит так ...
julien
2

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

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

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

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

pcapademic
источник
Может ли beagle обрабатывать нестандартные файлы?
Чарльз Стюарт
@ Чарльз Стюарт - ты имеешь в виду нетекстовые файлы?
pcapademic
Нет, я имею в виду файлы устройств, символические ссылки, FIFO и т. Д.
Чарльз Стюарт
Эта ссылка не относится к проекту об организации документа.
детально
1

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

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

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

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

PBR
источник
0

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

https://github.com/alvatar/dfym

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

alvatar
источник
0

TMSU

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

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

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

justsomeguy
источник
1
Вы пропустили это ... это самый высоко оцененный ответ
pufferfish
-1

Я предлагаю взглянуть на систему контроля версий, такую ​​как 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

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

Colin
источник