Pull to refresh

Comments 50

UFO just landed and posted this here
Читал по диагонали, не понял, какую проблему решали то? Что плохого в древовидном json например?
Спасибо за минуса, товарищи. Я перечитал статью. Всё равно не понял, ибо человек сначала придумал себе проблемы, потом их героически решил.
UFO just landed and posted this here
Я не понял в чем проблема хранить файлово то, к чему хочется обращаться как к файлам.
Может быть, я не достаточно аккуратно изложил проблему.

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

Вот и все дела.
Этот файл вами и создан, как я понимаю. В чём проблема создать N файлов так как вам хочется иерархически?
Вы не читаете то, что я уже написал: файл нужен как единое целое в другом месте.

Более того, этот скрипт и делает это самое «создать N файлов иерархически» совершенно автоматически.
синхронизировать между машинами или каким-либо скриптом обрабатывать один файл все же легче
Но синхронизация как раз таки файловая же везде нынче. Файлы — проще. Синхронизация отдельных файлов — быстрее.

А по скриптам — так вообще не понял, наоборот же, проще каждому скрипту рассказать в какой файл он должен писать, чем объяснить структуру единого файла.

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


Именно про это я и говорю. Писать легче в отдельные файлы. Поэтому большой конфиг превращается в файлы.

Но этот же конфиг мне нужен как один штука, потому что только один штука на входе понимает та система, которая его переваривает. Вот и все дела :-)
Ааа, просто есть ещё какая то система. Вот про это в шапке что-то не уловил и не понял в итоге зачем. Всё, тогда понятно, спасибо.
\<offtop\>
У меня другая проблема – не могу придумать правильную структуру каталогов (классификацию файлов), т.е. есть много файлов, которые можно отнести сразу в несколько папок, городить ссылки из одной папки в другую как-то мягко говоря не правильно.
Такое ощущение, что нужно писать базу данных с ссылками на локальные файлы и задавать им классификацию (категории, метки, темы и т.п.), далее к этому уже интерфейс какой-то… Каталогизатор какой-то получается.
\</offtop\>
Есть-же такая штука — жёсткая ссылка.
Вот только как реализовать.:( С питоном я никак от слова совсем…

Стесняюсь спросить, а при чем здесь Питон?

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
С учетом, что я это планировал делать для удобного обмена файлами между людьми, которые слабо понимают в IT (самому перелопатить все да потом поддерживать — нереально)…


Рискну «влезть» — из серии «хорошо забылое старое».

Были на заре такие файловые менеджеры — Volkov Commander и DOS Navigator. Кто у кого тогда «спёр» идею, сейчас уже не угадаешь, но умели они, как и FIDO-шный софт править файлы-компаньоны (как минимум — files.bbs и descript.ion) — в частности при копировании с места на место.

По сути — та же БД со спец. инструментом, но вполне доступным, встроенным в файловый менеджер (ну, да, какое-то расширение для GUI-евых «проводнико» напрашивается) и годным для людей, далеких от IT.

Некоторые мои знакомые архивариусы (из совсем не молодых ещё по тем временам) с огромным удовольствием пользовались такой возможностью и этого им вполне хватало (в купе с ручной правкой/написанием содержимого files.bbs — ну не было тогда готовых отдельных редакторов)
UFO just landed and posted this here
А почему «рискну»?
Тут любые варианты интересны

Это, скорее, хабра-призказка ;)
Для себя искал и порывался написать «тегировалку» фото коллекции — после ухода с винды, где этого добра валом, но как-то «отпустило» или стало лень

А на предмет вариантов — из той же серии: берём графические редакторы или даже более-менее старые фотоаппараты с поддержкой RAW — там к каждому файлу, который «неизменен», прикладывается мелкий (.thm, .xmp и т.п.) со всякими разностями — от режима «проявки» RAW, до истории изменений и тегов.

Из готового — тот же shotwell под линукс — умеет коллекции тегов с сортировкой/выборкой. По отдельной команде записывает теги в файлы, если поддержка, как у jpeg. Далее такой файл переносится на другой комп, а там теги вычитываются и кладутся в локальную базу. Вроде бы оно даже умело интегрироваться с «родными» проводниками для Gnome/KDE a'la дополнительные атрибуты файлов.
есть много файлов, которые можно отнести сразу в несколько папок

Значит пора отказываться от концепции «папок» в пользу концепции «меток».


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

Правильно. Все каталоги у нас теперь не «папки», а «метки», и все ссылки на один и тот же документ должны быть равноправны, то есть есть это должны быть жесткие ссылки, а не символьные.


Единственная проблема — ext[234], в отличие от, например, NTFS, не хранит обратных ссылок с инодов на файлы, а поэтому, если стороннего индекса нет, то для удаления документа, если такое вдруг понадобится, придется делать полный перебор:


$ find ~/ -xdev -samefile useless-file.org -delete

Для резервирования такой ФС, rsync(1)’у надо будет додать ключ -H.


В остальном — никаких особенностей.

UFO just landed and posted this here
хочу часть[ю] своей базы схем поделиться с кем-то

Если часть — это такие-то метки со всем, что под ними лежит, то просто — тем же 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"
UFO just landed and posted this here
Ну, одну я уже упомянул — NTFS. :-)

Есть ли *стандартные* файловые системы, что хранят обратные ссылки с инодов на файлы, вы хотите спросить? А вот не знаю — интересовался этим весьма поверхностно.
UFO just landed and posted this here
отличное решение!
до этого я только предполагал такую реализацию через плагин VFS для Midnight Commander. Там мне показалось не так удобно как с fusepy))
Парсинг все равно происходит и все запросы парсера файловой системы пройдут через ядро. Гораздо быстрее работать с единым файлом напрямую. Но как задача для знакомства с fusepy — годится.
Я вроде не написал, что данное решение мне срочно надо использовать для обработки миллионов запросов в секунду…

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

И если вам действительно надо условный миллион раз за условную же наносекунду читать конфиг, то, быть может, вы что-то делалете не то..?
Конечно, я часто делаю что-то не так. А кто не ошибается? Но работа приучила меня проектировать так, чтобы задача решалась с наименьшим выделением тепла. Это нравится экологам и в итоге не приносит неприятных сюрпризов с ростом обрабатываемой информации.
Вы же понимаете, что на один шаг парсера файловой системы будет 4(!) переключения из юзерспейса в ядро и обратно?
Здесь гораздо интереснее будет инвертировать задачу: раскидать много малых файлов по реальной файловой системе и предоставить один виртуальный для КЭШированного доступа.
В итоге и применять можно оба подхода и системные вызовы экономятся.
Ну да, отчасти вы, конечно, правы. С другой стороны, у меня было несколько часов на все про все, и тут уж не до спасения планеты. :-)

Ваша идея тоже звучит интересно, признаться, но это ваша идея и ваш интерес, не могу ж я их взять и украсть :-)
А что за ад из переносов строки в тексте статьи?
Хабр не вполне корректно обрабатывает переносы. Спасибо, исправил.
Редактирование определенно необходимо. Я бы даже очень был рад полному интерфейсу
Похожую тему рассказывали про ОС Plan9. Её постоянным пользователем является (как оказалось) некий ВУЗ Барселоны, занимающийся переводами текстов. Им очень нравится, что в основе ОС многоязыковость и при этом очень легко создавать свои специализированные файловые системы. Вот они дожились до того, чтобы переводить тексты при помощи таких файловых систем — документ делится на разделы, разделы переводят разные люди — для ускорения. И вот здесь фишки Plan9 им оказываются очень впору. Если интересно, можно раскопать, как у них это происходило — у автора статьи очень похожий — и правильный! — взгляд на схожую проблему. Круто решать такие задачи :-)
Да, мне очень нравится этот подход, когда все — файлы, и поэтому все инструменты являются универсальными.

собственно говоря, FUSE, Sysfs и procfs в Линуксах появились по мотивам разработок Plan9
А чем ZIM не подошел(не имею ввиду портирования файлов в него)?
Глянув на его код можно было и немного переиначить, а потом «натравить» на свои.
ZIM, который формат файла? А при чем здесь вообще конкретный формат файла?

Статья ведь про то, что файлы с иерархией можно легко монтировать как файловую систему, и тогда для работы с содержимым можно пользоваться любыми привычными инструментами.
ZIM — программа, домашнее wiki. На питоне.
файлы с иерархией можно легко монтировать как файловую систему

Я про это и сказал, что вместо того, чтобы разрабатывать с нуля, можно было посмотреть, как программа делает из одного файла древовидную структуру. А потом, на том же питоне(zim на питоне), написать код под персональные нужды.
Ссылка: https://ru.wikipedia.org/wiki/Zim
У меня нет проблемы сделать из файла древовидную структуру :-) Такие вещи называются парсерами, и с этим уже давно ни у кого нет проблем.

У меня проблема — представление одной древовидной структуры в виде другой, файловой.
Эммм… А я разве о другом? Там, в проге есть разделение(типа офисовского «совместного использования файла»(зависит от версии)). Как прога предоставляет ее по сети? Разве не файловой системой?
Тут, мне кажется, спор излишен, ибо я говорил о «посмотреть код программы», а вы так и становились на файловой системе.
Т.е. вы предлагаете адаптировать программу, визуально отображающую файлы с вики-подобной разметкой в виде дерева..?

Я, вероятно, не совсем вас сразу понял.
Не совсем. Просто посмотреть код и взять нужное для себя.
А что вообще мне там может быть нужно, в этом коде? Т.е., зачем мне разбираться в софтине на тысячи строк кода, когда все решение занимает меньше двух сотен строк?

Опять же, какое отношение софт для просмотра файлов с вики-подобным синтаксисом имеет к скриптам, работающим с файловой системой?
Sign up to leave a comment.

Articles