Comments 50
Есть единый сложный файл, который в принципе кормится одной системе как единый файл, и с этим трудно что-то сделать. С другой стороны, хочется с некоторыми ветками дерева этого файла работать прямо из консоли, простыми скриптами.
Вот и все дела.
Более того, этот скрипт и делает это самое «создать N файлов иерархически» совершенно автоматически.
синхронизировать между машинами или каким-либо скриптом обрабатывать один файл все же легчеНо синхронизация как раз таки файловая же везде нынче. Файлы — проще. Синхронизация отдельных файлов — быстрее.
А по скриптам — так вообще не понял, наоборот же, проще каждому скрипту рассказать в какой файл он должен писать, чем объяснить структуру единого файла.
Привязка к одному файлу у вас идеалогическая, имхо, а не техническая.
А по скриптам — так вообще не понял, наоборот же, проще каждому скрипту рассказать в какой файл он должен писать, чем объяснить структуру единого файла.
Именно про это я и говорю. Писать легче в отдельные файлы. Поэтому большой конфиг превращается в файлы.
Но этот же конфиг мне нужен как один штука, потому что только один штука на входе понимает та система, которая его переваривает. Вот и все дела :-)
У меня другая проблема – не могу придумать правильную структуру каталогов (классификацию файлов), т.е. есть много файлов, которые можно отнести сразу в несколько папок, городить ссылки из одной папки в другую как-то мягко говоря не правильно.
Такое ощущение, что нужно писать базу данных с ссылками на локальные файлы и задавать им классификацию (категории, метки, темы и т.п.), далее к этому уже интерфейс какой-то… Каталогизатор какой-то получается.
\</offtop\>
Вот только как реализовать.:( С питоном я никак от слова совсем…
С учетом, что я это планировал делать для удобного обмена файлами между людьми, которые слабо понимают в IT (самому перелопатить все да потом поддерживать — нереально)…
Рискну «влезть» — из серии «хорошо забылое старое».
Были на заре такие файловые менеджеры — Volkov Commander и DOS Navigator. Кто у кого тогда «спёр» идею, сейчас уже не угадаешь, но умели они, как и FIDO-шный софт править файлы-компаньоны (как минимум — files.bbs и descript.ion) — в частности при копировании с места на место.
По сути — та же БД со спец. инструментом, но вполне доступным, встроенным в файловый менеджер (ну, да, какое-то расширение для GUI-евых «проводнико» напрашивается) и годным для людей, далеких от IT.
Некоторые мои знакомые архивариусы (из совсем не молодых ещё по тем временам) с огромным удовольствием пользовались такой возможностью и этого им вполне хватало (в купе с ручной правкой/написанием содержимого files.bbs — ну не было тогда готовых отдельных редакторов)
А почему «рискну»?
Тут любые варианты интересны
Это, скорее, хабра-призказка ;)
Для себя искал и порывался написать «тегировалку» фото коллекции — после ухода с винды, где этого добра валом, но как-то «отпустило» или стало лень
А на предмет вариантов — из той же серии: берём графические редакторы или даже более-менее старые фотоаппараты с поддержкой RAW — там к каждому файлу, который «неизменен», прикладывается мелкий (.thm, .xmp и т.п.) со всякими разностями — от режима «проявки» RAW, до истории изменений и тегов.
Из готового — тот же shotwell под линукс — умеет коллекции тегов с сортировкой/выборкой. По отдельной команде записывает теги в файлы, если поддержка, как у jpeg. Далее такой файл переносится на другой комп, а там теги вычитываются и кладутся в локальную базу. Вроде бы оно даже умело интегрироваться с «родными» проводниками для Gnome/KDE a'la дополнительные атрибуты файлов.
есть много файлов, которые можно отнести сразу в несколько папок
Значит пора отказываться от концепции «папок» в пользу концепции «меток».
городить ссылки из одной папки в другую как-то мягко говоря не правильно
Правильно. Все каталоги у нас теперь не «папки», а «метки», и все ссылки на один и тот же документ должны быть равноправны, то есть есть это должны быть жесткие ссылки, а не символьные.
Единственная проблема — ext[234], в отличие от, например, NTFS, не хранит обратных ссылок с инодов на файлы, а поэтому, если стороннего индекса нет, то для удаления документа, если такое вдруг понадобится, придется делать полный перебор:
$ find ~/ -xdev -samefile useless-file.org -delete
Для резервирования такой ФС, rsync(1)
’у надо будет додать ключ -H
.
В остальном — никаких особенностей.
хочу часть[ю] своей базы схем поделиться с кем-то
Если часть — это такие-то метки со всем, что под ними лежит, то просто — тем же rsync -aH
.
вместе со всеми «тегами» конкретных файлов
А вот есть так, то есть если часть — это отдельные документы, размазанные по всему дереву меток, то опять же — только полным перебором. Увы, не хранит ext обратные ссылки.
Мне это ни разу не было не нужно, так что костыля я не написал, но понятно, что он элементарный.
Мне это ни разу не было не нужно, так что костыля я не написал, но понятно, что он элементарный.
А вообще, что уж там, давайте напишем:
#!/bin/bash
# config
TREE_ROOT="$HOME/origami"
SCRIPTNAME='amoralist-cp'
USAGE=$"Usage: $SCRIPTNAME <source>... <dest>"
(($# >= 2)) || { printf >&2 '%s\n' "$USAGE"; exit 0; }
dest="${!#}"
for ((i = 1; i <= $# - 1; i++)); do
if [[ -d ${!i} ]]; then
printf >&2 '%s\n' $"${!i} is directory; ignored"
else
find_argv+=('-samefile' "${!i}" '-or')
fi
done
unset find_argv[-1]
find "$TREE_ROOT" -xdev "${find_argv[@]}" -printf '%P\n' \
| rsync --archive --hard-links --files-from - "$TREE_ROOT" "$dest"
до этого я только предполагал такую реализацию через плагин VFS для Midnight Commander. Там мне показалось не так удобно как с fusepy))
Для скорости я бы писал не на Питоне, и обрабатывал системные вызовы бы не в один поток, и т.д. и т.п. В конце концов можно написать модуль файловой системы для ядра.
И если вам действительно надо условный миллион раз за условную же наносекунду читать конфиг, то, быть может, вы что-то делалете не то..?
Вы же понимаете, что на один шаг парсера файловой системы будет 4(!) переключения из юзерспейса в ядро и обратно?
Здесь гораздо интереснее будет инвертировать задачу: раскидать много малых файлов по реальной файловой системе и предоставить один виртуальный для КЭШированного доступа.
В итоге и применять можно оба подхода и системные вызовы экономятся.
Глянув на его код можно было и немного переиначить, а потом «натравить» на свои.
Статья ведь про то, что файлы с иерархией можно легко монтировать как файловую систему, и тогда для работы с содержимым можно пользоваться любыми привычными инструментами.
файлы с иерархией можно легко монтировать как файловую систему
Я про это и сказал, что вместо того, чтобы разрабатывать с нуля, можно было посмотреть, как программа делает из одного файла древовидную структуру. А потом, на том же питоне(zim на питоне), написать код под персональные нужды.
Ссылка: https://ru.wikipedia.org/wiki/Zim
У меня проблема — представление одной древовидной структуры в виде другой, файловой.
Тут, мне кажется, спор излишен, ибо я говорил о «посмотреть код программы», а вы так и становились на файловой системе.
Я, вероятно, не совсем вас сразу понял.
Файловая система, дешево и быстро