Может быть, я не достаточно аккуратно изложил проблему.

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

Вот и все дела.

MonkAlex 21 ноя 2016 в 14:13

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

VlK 21 ноя 2016 в 14:45

Вы не читаете то, что я уже написал: файл нужен как единое целое в другом месте.

Более того, этот скрипт и делает это самое «создать N файлов иерархически» совершенно автоматически.

MonkAlex 21 ноя 2016 в 14:57

синхронизировать между машинами или каким-либо скриптом обрабатывать один файл все же легче

Но синхронизация как раз таки файловая же везде нынче. Файлы — проще. Синхронизация отдельных файлов — быстрее.

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

Привязка к одному файлу у вас идеалогическая, имхо, а не техническая.

VlK 21 ноя 2016 в 16:34

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

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

Но этот же конфиг мне нужен как один штука, потому что только один штука на входе понимает та система, которая его переваривает. Вот и все дела :-)

MonkAlex 21 ноя 2016 в 16:49

Ааа, просто есть ещё какая то система. Вот про это в шапке что-то не уловил и не понял в итоге зачем. Всё, тогда понятно, спасибо.

Rampages 19 ноя 2016 в 21:11

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

Evengard 19 ноя 2016 в 21:25

Вам тегировать файлы нужно. Посмотрите в сторону чего нить вроде https://www.tagsistant.net/

roach1967 20 ноя 2016 в 01:07

Есть-же такая штука — жёсткая ссылка.
Вот только как реализовать.:( С питоном я никак от слова совсем…

lightman 20 ноя 2016 в 11:51

os.link

Z-r 20 ноя 2016 в 19:34

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

НЛО прилетело и опубликовало эту надпись здесь

av0000 22 ноя 2016 в 22:14

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

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

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

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

Некоторые мои знакомые архивариусы (из совсем не молодых ещё по тем временам) с огромным удовольствием пользовались такой возможностью и этого им вполне хватало (в купе с ручной правкой/написанием содержимого files.bbs — ну не было тогда готовых отдельных редакторов)

НЛО прилетело и опубликовало эту надпись здесь

av0000 23 ноя 2016 в 08:45

А почему «рискну»?
Тут любые варианты интересны

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

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

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

Z-r 20 ноя 2016 в 16:02

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

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

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

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Z-r 20 ноя 2016 в 18:08

хочу часть[ю] своей базы схем поделиться с кем-то

Если часть — это такие-то метки со всем, что под ними лежит, то просто — тем же rsync -aH.

вместе со всеми «тегами» конкретных файлов

А вот есть так, то есть если часть — это отдельные документы, размазанные по всему дереву меток, то опять же — только полным перебором. Увы, не хранит ext обратные ссылки.

Мне это ни разу не было не нужно, так что костыля я не написал, но понятно, что он элементарный.

Z-r 20 ноя 2016 в 19:46

Мне это ни разу не было не нужно, так что костыля я не написал, но понятно, что он элементарный.

А вообще, что уж там, давайте напишем:

#!/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"

НЛО прилетело и опубликовало эту надпись здесь

Z-r 24 ноя 2016 в 14:18

Ну, одну я уже упомянул — NTFS. :-)

Есть ли *стандартные* файловые системы, что хранят обратные ссылки с инодов на файлы, вы хотите спросить? А вот не знаю — интересовался этим весьма поверхностно.

НЛО прилетело и опубликовало эту надпись здесь

ser-mk 20 ноя 2016 в 01:07

отличное решение!
до этого я только предполагал такую реализацию через плагин VFS для Midnight Commander. Там мне показалось не так удобно как с fusepy))

Str3lok 20 ноя 2016 в 01:07

Парсинг все равно происходит и все запросы парсера файловой системы пройдут через ядро. Гораздо быстрее работать с единым файлом напрямую. Но как задача для знакомства с fusepy — годится.

VlK 20 ноя 2016 в 01:13

Я вроде не написал, что данное решение мне срочно надо использовать для обработки миллионов запросов в секунду…

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

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

Str3lok 20 ноя 2016 в 10:20

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

-2

VlK 20 ноя 2016 в 16:12

Ну да, отчасти вы, конечно, правы. С другой стороны, у меня было несколько часов на все про все, и тут уж не до спасения планеты. :-)

Ваша идея тоже звучит интересно, признаться, но это ваша идея и ваш интерес, не могу ж я их взять и украсть :-)

maxzhurkin 20 ноя 2016 в 01:21

А что за ад из переносов строки в тексте статьи?

VlK 20 ноя 2016 в 01:22

Хабр не вполне корректно обрабатывает переносы. Спасибо, исправил.

Rigidus 20 ноя 2016 в 01:30

Редактирование определенно необходимо. Я бы даже очень был рад полному интерфейсу

bitterman 20 ноя 2016 в 14:27

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

VlK 20 ноя 2016 в 16:08

Да, мне очень нравится этот подход, когда все — файлы, и поэтому все инструменты являются универсальными.

собственно говоря, FUSE, Sysfs и procfs в Линуксах появились по мотивам разработок Plan9

delvin-fil 20 ноя 2016 в 16:03

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

VlK 20 ноя 2016 в 16:05

ZIM, который формат файла? А при чем здесь вообще конкретный формат файла?

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

delvin-fil 21 ноя 2016 в 08:29

ZIM — программа, домашнее wiki. На питоне.

файлы с иерархией можно легко монтировать как файловую систему

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

VlK 21 ноя 2016 в 10:53

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

У меня проблема — представление одной древовидной структуры в виде другой, файловой.

delvin-fil 21 ноя 2016 в 11:04

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

VlK 21 ноя 2016 в 16:44

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

Я, вероятно, не совсем вас сразу понял.

delvin-fil 22 ноя 2016 в 06:59

Не совсем. Просто посмотреть код и взять нужное для себя.

VlK 22 ноя 2016 в 13:33

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

Файловая система, дешево и быстро

Комментарии 50

Публикации

Истории