Що є хорошим рішенням для тегів файлів у Linux? [зачинено]

Я шукав спосіб позначити свої файли та шукати / фільтрувати їх на основі цих тегів.

Ось мої ( оновлені ) вимоги:

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

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

Гаразд, Бігль має величезні залежності від гнома, а трекер - це нормально, але все-таки є деякі залежності, які мені не подобаються ...

Проводили ще кілька досліджень, і цей шлях можна було б розширити атрибутами файлів .
Це нативне рішення для більшості останніх файлових систем, але вони ще не дуже добре підтримуються (більшість 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і у нас є ефективний спосіб знайти, які шляхи мають заданий inode , ми можемо це зробити, втрачаючи теги, лише якщо ми переходимо з файлових систем. Копіювання файлів може створити певні проблеми, і це явно складніше, ніж моя оригінальна пропозиція.
4. систему можна було б створити резервну копію - не дуже важко.
5. немає залежностей від будь-якого середовища робочого столу - немає
6. якщо задіяний якийсь gui, мусить бути резервний кліп - саме там ми живемо!

Постскрипт Файл "зворотного введення-пошуку", описаний за посиланням (2), який ви мені показали у своїй відповіді на (1), може використовуватися для надання деякої додаткової інфраструктури. Ми можемо запустити службу у файлі зворотного пошуку, який перевіряє, чи відповідає кожен inode, вказаний у імені файлу тегу, відповідний входу файла (якщо такий є), на який вказує тег. Якщо немає відповідності, то може бути проведена необхідна операція (чи існує ще одна індея? Де це?), А файл зворотного пошуку або мутується, або регенерується, і тег посилається на оновлення.

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

Щойно я випустив альфа своєї нової програми, яка намагається надати цю функціональність. В даний час він відповідає деяким, але не всім, вашим вимогам. Це може вас зацікавити в будь-якому випадку. Він надає інструмент командного рядка для тегів та віртуальну файлову систему для перегляду (де теги представлені в каталогах).

http://www.tmsu.org/

будь-який файл, прочитаний користувачем, можна вільно помітити

Так.

користувач може шукати файли, що відповідають одному або декільком тегам

Так. Або через інструмент командного рядка, або за допомогою перегляду каталогів тегів у віртуальній файловій системі.

файли можна переміщувати, не втрачаючи раніше пов’язаних тегів

Ні. Однак додаток зберігає відбитки пальців файлів з тегами, які використовуються для ідентифікації переміщених файлів. Передбачена команда «ремонт», яка оновлює шляхи переміщення файлів. (Очевидно, цей механізм виходить з ладу, якщо файл переміщений і змінений.)

система може бути резервна копія легко

Так. Це простий файл бази даних Sqlite 3.

відсутність залежності від будь-якого середовища робочого столу

Так. Ніяких залежностей, і оскільки його можна запускати як віртуальну файлову систему, її можна переглянути як файлову систему в будь-якій програмі, що підтримує символічні посилання.

якщо задіяний якийсь gui, повинен бути резервний кліп

Наразі немає графічного інтерфейсу.

Я думаю, що це може відповідати всім вашим вимогам. У будь-якому випадку, це класний фрагмент коду:

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

GUI вимагає Qt, але є програма командного рядка для пошуку, і той факт, що всі теги є насправді у імені файлу, робить його тривіальним для маніпулювання тегів | файлів із кліпу.

Ніхто не згадував, але ви обов'язково повинні ознайомитися з розширеними атрибутами файлової системи. Наприклад, ext4 має їх. є інструменти getfattr і setfattr для боротьби з ними. Звичайно, вам доведеться написати кілька скриптів оболонки, щоб шукати файли, позначені тегом. Щодо згаданих питань, усі відповіді - "Так". Вам слід врахувати лише те, що це залежить від файлової системи.

Здивований, що ніхто не згадав про TagSpaces . Він відповідає всім вашим вимогам, оскільки теги зберігаються у імені файлу, а TagSpaces є кросплатформенним.

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

Ця остання стаття про інструменти пошуку для робочого столу Linux згадує, що Tracker підтримує теги. На жаль, у старій версії, яку вони тестували, вона повинна бути напівзламанною. Може, це зараз виправлено?

1. Не широка система.
2. Ви можете створити резервну копію.
3. Він в комплекті з Gnome.

Спробуйте Бігль . Я вважаю це досить добре.

Він може не відповідати всім вимогам, і я не впевнений, що міг би. Наприклад, чи підтримують файли FIFO розширені атрибути? Якщо цього немає, Бігль має резервну базу даних.

Деякі інші альтернативи можуть бути тагастичними , тегфами або данталійськими .

Таким чином, ви не знайдете інтеграцію Nepomuk у gnome, у командному рядку чи деінде в Linux.

І навпаки, з Tracker ви не знайдете інтеграцію kde AFAIK. Не впевнений у CLI.

Тож, на жаль, здається, що відповідь "ні".

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

Я зробив невелику програму, яка використовує для цієї мети SQLite. Це вирішило мою потребу, але, можливо, це теж допоможе вам:

https://github.com/alvatar/dfym

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

ТМСУ

TMSU - це інструмент для позначення ваших файлів. Він надає просту утиліту командного рядка для застосування тегів та віртуальної файлової системи, щоб надати вам теги на основі файлів з будь-якої іншої програми.

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

Здивований, про це ніхто не згадав.

Я пропоную ознайомитись із системою контролю версій, такою як Subversion, для таких функцій над і поза файловою системою. Деякі можуть підійти вам краще, ніж інші, але загалом:

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

Приклад кліпу з 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

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