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