LINUX.ORG.RU

Подскажите хороший способ локально хранить заметки с тегами

 , , ,


0

8

Ищу правильный юниксовый способ для ведения разнообразных записей с тегами, в крайнем случае открытую программу допускающую синхронизацию заметок на нескольких устройствах с Linux и Android без использования внешних сервисов.

Основное требование: независимость от внешних сервисов и интернета, надёжность, открытость способа хранения (формата), чтобы записи можно было прочитать через 20 и более лет.

В идеале хотелось бы делать это через тегирование текстовых (и не только) файлов на уровне ФС: что-то аналогичное chmod/lsmod и chattr/lsattr, но таких функций я не знаю. Хороших костылей также не нашёл.

Проблему синхронизации между устройствами планирую решать используя syncthing или его аналоги.

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

Что посоветуете?


Ответ на: комментарий от energetix_user

Нет-нет, костылей не хочется.

Хочется простоты, надёжности и возможности обращения к записям через много лет. Например, программа, хранящая записи в непонятном формате, которую единственный автор забросит через месяц, а через год уже не будет собираться — не годится. Годится, например, тегирование на уровне ФС, но его пока нет.

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

ioctl ()

чтобы записи можно было прочитать через 20 и более лет

Боюсь, что только бумага. Если хочется написал и забыл. А так придётся время от времени их копировать куда-нибудь.

Так же можешь писать свои записи в эпик-треды, а кто-нибудь их и сохранит.

anonymous ()
Ответ на: комментарий от anonymous

Боюсь, что только бумага. Если хочется написал и забыл. А так придётся время от времени их копировать куда-нибудь.

Копировать для поддержания актуальной аппаратной базы допустимо. Пока не было случая, чтобы я не смог скопировать старые файлы при обновлении железа.

Tagsistant и пр. смотрел, но база SQL несколько не соответствует первоначальным условиям. Кроме того, подозреваю, с копированием и синхронизацией будут проблемы.

MobileOrg и Dokuwiki любопытны, но это несколько не для того.

Пока ходил по ссылкам наткнулся на стандартные утилиты attr, getfattr и setfattr. Для интересующихся хорошая ссылка: http://www.lesbonscomptes.com/pages/extattrs.html Кажется, это то, что нужно. Жаль средства для работы с ними не очень развиты (даже в find не поддерживаются). Ну и с Android и syncthing тоже не ясная ситуация.

ioctl ()
Ответ на: комментарий от ioctl

Ну порт того же Tagsistant на андроид есть, насчёт syncthing не знаю, но btsync работает на ведре вполне хорошо. Собственно у тебя по итогам треда: 1. Писать все теги в отдельный файл, либо в БД тагсистентом, либо самописной утилитой во что угодно. 2. Либо записывать в имя файла или в сам файл и впоследствии парсить самописной утилитой.

Всякие getattr с chmodами явно при синхронизации будут обрезаться.

Либо же бросить идею с хранением в фс и использовать тот же evernote, tomboy, менеджеры паролей всех сортов.

energetix_user ()

В идеале хотелось бы делать это через тегирование текстовых (и не только) файлов на уровне ФС: что-то аналогичное chmod/lsmod и chattr/lsattr, но таких функций я не знаю.

xa-tags, см «dumb mode», хранит в xattr

Но по опыту использования, это неудобно. Теги слетают при обычном копировании.

Наиболее надёжный и переносимый способ - внедрять в имя файла. Типа «[tag1][tag2] filename.jpg». Искать - find'ом.

anonymous ()

юниксовый способ ведения записей с тэгами

Файловое дерево же. Метки — каталоги. В них жесткие ссылки на файлы.

Проблему синхронизации между устройствами планирую решать используя syncthing или его аналоги.

Не знаю за syncthing, но обычный rsync(1) не множить при копировании один файл, когда на него несколько ссылок, умеет.

Zmicier ★★★★★ ()
Ответ на: комментарий от gag

rsync поддерживает xattr.

Никогда им осознанно не пользовался. Сходу не смог найти режим одноранговой синхронизации, а не только SRC->DST. Например, есть две синхронизированные папки d1 и d2 (возможно, на разных устройствах), в каждой по четыре файла: fa fb fc fd.

Потом делаю

rm d1/fa
rm d2/fb
echo aaa >> d1/fc
echo bbb >> d2/fd

После синхронизации хотелось бы получить в каждой папке по файлу fc и fd с aaa и bbb в конце соответственно. Syncthing такое умеет (по крайней мере «сложное» удаление я проверял). Это можно сделать через rsync?

ioctl ()
Ответ на: комментарий от anonymous

xa-tags, см «dumb mode», хранит в xattr

Я уже было обрадовался, но потом попробовал собрать и запустить. Программа уже сейчас «из коробки» не собирается. Так она ещё и теги норовит хранить в базе SQL. С ключём -M дела обстоят получше, только не пойму, зачем теги хранить в одной строке и в одном значении, которое, к тому же, надо декодировать. Да и поиск в таком режиме у него не работает.

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

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

Наиболее надёжный и переносимый способ - внедрять в имя файла. Типа «[tag1][tag2] filename.jpg». Искать - find'ом.

Это да. Только уж очень неудобно.

ioctl ()
Ответ на: комментарий от Zmicier

Файловое дерево же. Метки — каталоги. В них жесткие ссылки на файлы.

Кстати, неплохой способ, с рядом преимуществ: стандартнее некуда, быстрый поиск и просмотр в одном месте всех файлов в общим тегом.

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

ioctl ()

Ну я много чего перепробовал. Сначала был CherryTree и KeepNote, там хорошая иерархия и приятный гуй, но нет тегов. Потом был MyTetra, хороший функционал, но не очень приятный гуй. Сейчас таки сижу на Evernote, потому что очень простая синхронизация, удаленный доступ и очень хорошо сохраняет веб страницы. Способов сделать то же самое, но локально, я не нашел. Возможно только вики-движок с таксономическим поиском сможет сравняться, но это требует аццкого времени, которого у меня нет.

Lordwind ★★★★★ ()

тегирование текстовых (и не только) файлов на уровне ФС

Переходи на Haiku и BeFS, там такое из коробки есть.

Либо статический блог на localhost.

log4tmp ★★★★ ()
Ответ на: комментарий от ioctl

Это можно сделать через rsync?

Думаю, нет. rsync это SRC->DST с опцией удалять на DST того, чего нет на SRC. Тогда можно было бы посмотреть на unison, если бы он поддерживал xattr.

gag ★★★★★ ()
Ответ на: комментарий от ioctl

Сейчас запрещено создавать ссылки на каталоги, то есть, тегировать папки не выйдет

Да. С той лишь разницей, что при таком подходе каталоги — они и не папки вовсе, а именно метки (тэги). То есть не выйдет сделать одну и ту же метку вложенной в более чем одну. Но обратите внимание, что большинство реализаций меток вложений вообще не позволяет. Что дает повод задуматься — так уж ли это нужно.

При копировании между FS метки потеряются.

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

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

?

Пардон, просто не понял. Уж что-то, а перемещение файлов внутри одной ФС при этом совершенно безболезненно.

Zmicier ★★★★★ ()
Ответ на: комментарий от Zmicier

необходимость копирования на не умеющую во множественные ссылки файловую систему (FAT32, какие еще?)

Честно говоря, за NTFS тоже нельзя ручаться — сама-то по себе она ссылки, конечно, умеет, но вот работает ли с ними ntfs-3g(8), rsync(1) — не проверял.

Zmicier ★★★★★ ()
Ответ на: комментарий от Zmicier

Сейчас запрещено создавать ссылки на каталоги, то есть, тегировать папки не выйдет

Да. С той лишь разницей, что при таком подходе каталоги — они и не папки вовсе, а именно метки (тэги).

Не очень понял, потому уточню. Я писал не про те каталоги, которые содержат ссылки (каталоги-теги), а про «обычные». Чтобы их протегировать таким способом, надо создать на них жёсткую ссылку, что запрещено (хотя раньше это можно было).

То есть не выйдет сделать одну и ту же метку вложенной в более чем одну. Но обратите внимание, что большинство реализаций меток вложений вообще не позволяет.

Ну, если хранить теги в ключах xattr, то не вижу никаких препятствий.

Что дает повод задуматься — так уж ли это нужно.

Пока тоже не понятно, зачем это может понадобиться.

При копировании между FS метки потеряются.

В каком смысле?

В смысле, что операция

 cp ~/file /mnt/disk/ 
не создаст метку на новой файловой системе. А
 mv ~/file /mnt/disk/ 
ещё и оставит содержимое файла на старой ФС.

Пардон, просто не понял. Уж что-то, а перемещение файлов внутри одной ФС при этом совершенно безболезненно.

Если все ссылки лежат в одной папке-теге, то не ясно, что делать с файлами, имеющими общее имя. Логично, что надо хранить ссылки в структуре каталогов, подобной той, в которой хранится «оригинальный» файл. Раз так, то и при переименовании хорошо бы следить за сохранением этой структуры внутри каталога-тега. Это уже перебор.

ioctl ()
Ответ на: комментарий от ioctl

Да. С той лишь разницей, что при таком подходе каталоги — они и не папки вовсе, а именно метки (тэги).

Не очень понял, потому уточню. Я писал не про те каталоги, которые содержат ссылки (каталоги-теги), а про «обычные».

То есть вы хотите одновременно использовать и метки и вложенные папки? А не запутаетесь?

То есть не выйдет сделать одну и ту же метку вложенной в более чем одну. Но обратите внимание, что большинство реализаций меток вложений вообще не позволяет.

Ну, если хранить теги в ключах xattr, то не вижу никаких препятствий.

А можно поподробнее? xattr(7) — это записи типа поле — значение, привязанные к каждому отдельному файлу? Какое тут дерево?

Что дает повод задуматься — так уж ли [вложенные метки] нужн[ы].

Пока тоже не понятно, зачем это может понадобиться.

Справедливости ради, мне понадобилось. Я так храню личную фотовидеотеку, и там помимо меток по событиям и по персонажам есть еще даты и места. Даты вложены все (то есть, например, не 2015-12-31, а 2016/12/31), а места — некоторые (какая-нибудь Болгария/Варна). Но ни то, ни другое естественным образом двояковложенным быть не могут, так что проблемы нет.

В смысле, что операция cp ~/file /mnt/disk/
не создаст метку на новой файловой системе.

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

Для копирования всей (или существенной части) картотеки можно использовать:

$ rsync -aH ~/photos/ /media/Z320G/

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

А mv ~/file /mnt/disk/ ещё и оставит содержимое файла на старой ФС.

Так это ж правильно.

Если вы захотите удалить файл уже после того, как назначили ему кучу меток, то, к сожалению, в отличие от NTFS, где в инодах хранятся обратные ссылки, в ext* остается только делать полный перебор:

$ find ~/photos/ -xdev -samefile IMG_20161107_104422.jpg -delete

Если все ссылки лежат в одной папке-теге, то не ясно, что делать с файлами, имеющими общее имя.

Вероятно то же, что вы делаете, когда вам надо положить одноименные файлы в один каталог-папку — переименовывать, что же еще.

Логично, что надо хранить ссылки в структуре каталогов, подобной той, в которой хранится «оригинальный» файл.

А что такое «оригинальный файл»? Все ссылки равноправны.

Zmicier ★★★★★ ()
Последнее исправление: Zmicier (всего исправлений: 1)
Ответ на: комментарий от ioctl

Всегда пожалуйста. Я бросил пилить этот проект, когда понял бесперспективность затеи.

Наверное стоит оторвать всё, кроме работы с xattr и оставить так, может кому пригодится.

anonymous ()

В dolphin этим пользуюсь:
http://itmages.ru/image/view/5198299/fc518084

По ссылке какой-то непонятный скан официальной бумаги.

Я тут начал использовать MyTetrta, которую пилит Xintrea.

Выглядит любопытно. Хотел поглядеть, но инструкций по сборке ,как и Makefile, в репозитории не обнаружилось.

ioctl ()
Ответ на: комментарий от ioctl

В dolphin этим пользуюсь:
http://itmages.ru/image/view/5198299/fc518084

По ссылке какой-то непонятный скан официальной бумаги.

Внизу смотри: Type; Size; Tags

Я тут начал использовать MyTetrta, которую пилит Xintrea.

Выглядит любопытно. Хотел поглядеть, но инструкций по сборке ,как и Makefile, в репозитории не обнаружилось.

www.linux.org.ru/forum/general/13017037 Читай эту тему, вполне реально его собрать.

log4tmp ★★★★ ()
Последнее исправление: log4tmp (всего исправлений: 1)
Ответ на: комментарий от ArcFi

Элементарно:

Что-то не того. Создаю папки и файлы:

mkdir /tmp/delme || exit 1
cd /tmp/delme; mkdir d1
echo 111 > d1/fa; echo 222 > d1/fb; echo 333 > d1/fc; echo 444 > d1/fd
cp -a d1 d2

rm d1/fa d2/fb
echo aaa >> d1/fc; echo bbb >> d2/fd

Даю команду:

$ bidirsync() { rsync -rtuv "$1" "$2"; rsync -rtuv "$2" "$1"; } ; bidirsync /tmp/delme/d1/ /tmp/delme/d2/
sending incremental file list
fb
fc
fd

sent 230 bytes  received 73 bytes  606.00 bytes/sec
total size is 16  speedup is 0.05
sending incremental file list
fa

sent 145 bytes  received 35 bytes  360.00 bytes/sec
total size is 20  speedup is 0.11

Проверяю

$ ls /tmp/delme/d1 /tmp/delme/d2
/tmp/delme/d1:
fa  fb  fc  fd

/tmp/delme/d2:
fa  fb  fc  fd

$ cat /tmp/delme/d1/*
111
222
333
aaa
444

$ cat /tmp/delme/d2/*
111
222
333
aaa
444

А надо бы получить по два файла в каждой папке с aaa и bbb на конце.

ioctl ()

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

taker ()

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

Юникс вей єто когда спеки протоколов и сервисов пишут в аскифайл с псевдографикой. Есно '[тег-куег] запись куяпись' >> mylog и не вьіьо

anonymous ()
Ответ на: комментарий от ArcFi

Там пауза в 1 секунду между старыми и новыми файлами

С паузой перед записью распространение содержимого заработало. Только зачем-то восстановились файлы, которые были специально удалены.

ioctl ()
Ответ на: комментарий от ioctl

зачем-то восстановились файлы, которые были специально удалены.

Откуда оно узнает, специально мы удали файлы, или их там не было изначально?
Чтобы что-то удалить, надо удалять из обоих каталогов, либо менять логику.

ArcFi ()
Ответ на: комментарий от log4tmp

| Читай эту тему, вполне реально его собрать.

Осилил таки. Очень полезная задумка, и автор обещает сохранять совместимость формата. Но кто поручится, что сам автор не забросит эту программу по той или иной причине? Тогда будет немало головной боли с экспортом xml-ной базы. В общем, для долгосрочного хранения я бы пока поостерёгся её использовать.

ioctl ()
Ответ на: комментарий от ioctl

MobileOrg и Dokuwiki любопытны, но это несколько не для того.

как раз для этого. Emacs org-mode простой текстовый файл с тегами, ссылками типа списка литературы, категориями. изучи мануал на org-mode, там довольно гибко — можно давать имена ссылки на ссылку в почте/irc/bbdb/whatever (написать свой протокол на elisp)

ещё см. tagstore — там теги хранятся в простом текстовом файле.

если хочешь чтобы твои особо ценные заметки читались и через 30 лет, используй простой текстовый формат.

В начале была командная строка...

METAPHOR SHEAR

I began using Microsoft Word as soon as the first version was released around 1985. After some initial hassles I found it to be a better tool than MacWrite, which was its only competition at the time. I wrote a lot of stuff in early versions of Word, storing it all on floppies, and transferred the contents of all my floppies to my first hard drive, which I acquired around 1987. As new versions of Word came out I faithfully upgraded, reasoning that as a writer it made sense for me to spend a certain amount of money on tools.

Sometime in the mid-1980's I attempted to open one of my old, circa-1985 Word documents using the version of Word then current: 6.0 It didn't work. Word 6.0 did not recognize a document created by an earlier version of itself. By opening it as a text file, I was able to recover the sequences of letters that made up the text of the document. My words were still there. But the formatting had been run through a log chipper--the words I'd written were interrupted by spates of empty rectangular boxes and gibberish.

Now, in the context of a business (the chief market for Word) this sort of thing is only an annoyance--one of the routine hassles that go along with using computers. It's easy to buy little file converter programs that will take care of this problem. But if you are a writer whose career is words, whose professional identity is a corpus of written documents, this kind of thing is extremely disquieting. There are very few fixed assumptions in my line of work, but one of them is that once you have written a word, it is written, and cannot be unwritten. The ink stains the paper, the chisel cuts the stone, the stylus marks the clay, and something has irrevocably happened (my brother-in-law is a theologian who reads 3250-year-old cuneiform tablets--he can recognize the handwriting of particular scribes, and identify them by name). But word-processing software--particularly the sort that employs special, complex file formats--has the eldritch power to unwrite things. A small change in file formats, or a few twiddled bits, and months' or years' literary output can cease to exist.

anonymous ()
Ответ на: комментарий от ioctl

читай мануал по Emacs org-mode

ну и прочие ништяки org-mode: agenda, TODO, хронометраж выполнения задач, календарь, экспорт в 10500 форматов, last but not least : org-mode babel, :noweb и «грамотное программирование» через «блоки кода» и «блоки данных»

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

anonymous ()