Не ясно, какой поиск вы хотите. Если вы хотите, чтобы он работал где-нибудь в Unix, а не только в вашем домашнем каталоге, и вы хотите выполнять поиск только по путям, следующая схема работоспособна, с небольшим количеством хакерских атак на оболочку и использованием стандартного расположенного locatedb:
- Каждый каталог, который содержит по крайней мере один файл с тегами, нуждается в стандартном подкаталоге, скажем
.path-tags ;
- Каждый файл в каталоге $ FILE со ссылкой $ TAG (которая не должна содержать символ
_) имеет ссылку $TAG_$FILE -> ../$FILE
Я оставляю вам детали скрипта locate-tag ; он должен быть с двумя или тремя строками, используя только команду locate и хакерскую оболочку. (Если вам интересно, я мог бы написать один).
Некоторые главы KDE говорили о такой схеме метаданных, хотя я не помню подробностей.
Также должна быть возможность делать более сложные, проверяющие контент тесты на основе этой схемы с похожим сценарием, обернутым вокруг find .
Мысли об обновленных требованиях
- любой файл, читаемый пользователем, может быть помечен свободно - да, проблем не должно быть
- пользователь может искать файлы, соответствующие одному или нескольким тегам - аналогично
- файлы можно перемещать без потери ранее связанных тегов - каталоги, в которых они находятся, можно свободно перемещать, но если файл перемещается из каталога, у нас возникают проблемы. Если теги приняли форму
$TAG_$INODE_$FILE и у нас есть эффективный способ определить, какие пути имеют заданный индекс, тогда мы можем сделать это, потеряв теги только в том случае, если мы выходим из файловых систем. Копирование файлов может создать некоторые проблемы, и это явно сложнее, чем мое первоначальное предложение.
- резервное копирование системы может быть легко - не сложно.
- нет зависимости от любой среды рабочего стола - нет
- если задействован какой-либо графический интерфейс, должен быть запасной вариант - вот где мы живем!
Постскриптум Файл «обратный поиск по иноду», описанный ссылкой (2), которую вы показали мне в своем ответе (1), может быть использован для создания некоторой дополнительной инфраструктуры. Мы можем запустить службу в файле обратного просмотра, который проверяет, что каждый индекс, указанный в имени файла тега, совпадает с индексом файла (если есть), на который указывает тег. Если совпадений нет, то можно выполнить требуемую операцию (существует ли инод? где это?), и файл обратного просмотра либо видоизменяется, либо регенерируется, а символические ссылки тега обновляются.
Я ожидаю одного хитрого случая: что, если файл с тегами не там, где теги говорят, что это должно быть, файл обратного поиска говорит, что он все еще существует, но блудный файл не там, где говорит файл поиска, файл поиска находится вне Дата? Есть несколько способов справиться с этим делом, но ни один из них не является идеальным. Кроме того, вся эта задача, кажется, подходит для Perl ...
