ZAN
mount /path/to/snapshot.fs /media/work -o loop

не очень то и кросплатформенноо :)) лучше в зипе :)

to ZZZ
а какой предполагаемый размер базы ?
сколько записей ? какой средний размер файла ?

evgenyl
не очень то и кросплатформенноо :))

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

Для обычной пользовательской программы это, конечно, плохая идея - слишком жестоко по отношению к пользователю =).
В этом случае, я бы написал обертку над берклием. Ключ - полный путь в базе, чтение и запись - посредством StringIO, в той же базе сохранять текущую директорию (директорию внутри базы, естесственно).

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

но вопрос в размерах, если вся база метров 50 а размеры файлов 20-30кб то просто в каком нить sqlite все хранить и не парится

ZAN и evgenyl:

ZZZ
P.S. Только не надо предлагать мне создавать пустой файл и форматировать его в ext2… Ну или маковый dmg…

Дело в том, что файл-база должен передоваться пользователю посредством сети… А 99.99% пользователей этого дела, как это не прискорбно, будут тупые маздаевцы. Ну будет ещё процент линуксоидов, сидящих под маздаем… Самой альтернативной мазадаю осью будет, как это ни странно, MacOS X… Ну да ладно, это всё лирика…

evgenyl
а какой предполагаемый размер базы ?
сколько записей ? какой средний размер файла ?

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

Глянул на SQLite… Сам SQLite замечательно с BLOB работает, а его питоная обёртка ничего кроме DB-API не видит в упор! Расстреливать за такое надо!
Смотрю банальный zipfile… Совсем опустился… А как ему поток передать и поток забрать? Я уже готов плюнуть на изменяемость, хотя бы быстрый доступ к конкретным файлам (tar никак не справляется!) и возможность потокого (чтобы не жрать память гигами и не создавать временные файлы) создавать эту, с позволения сказать, базу данных…
Может ISO? Есть что-нить на эту тему?

нее лучше тогда делай папку с файлами, центральное хранилище с rsync сервером
обновляй через rsync написанном на питоне
вот быстро нашел ссылку в гугле
http://www.vdesmedt.com/~vds2212/rsync.html
Быстро! надежно, плюс экономия трафика.

ISO read only

ZZZ
P.S. Только не надо предлагать мне создавать пустой файл и форматировать его в ext2… Ну или маковый dmg…

Что-то не обратил внимание на постскриптум…

ZZZ
Может ISO? Есть что-нить на эту тему?

Тогда может все-таки FAT32?

ZZZ
Смотрю банальный zipfile… Совсем опустился… А как ему поток передать и поток забрать?

Если вместо ZipFile.open использовать его конструктор, то можно передавать и поток, но это не решение проблемы, т.к. zip работать быстрее tar-а не будет.

SQLite, PostgreSQL и прочие реляционные базы данных не нужны, как и язык SQL запросов в целом. Cмотри лучше в сторону берклия - он быстрый + модель путь -> файл неплохо будет ложиться на архитектуру ключ -> значение, к тому же поддерживается стандартной поставкой питона.

evgenyl
нее лучше тогда делай папку с файлами, центральное хранилище с rsync сервером
обновляй через rsync написанном на питоне

Я уже думал об этом. Но никак не влазиет в концепцию, так что я бысто отказался.

evgenyl
ISO read only

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

ZAN
Тогда может все-таки FAT32?

Я только за! :-)
Но как?

ZAN
Если вместо ZipFile.open использовать его конструктор, то можно передавать и поток,

Нихрена не понимаю… Наверное уже совсем ум за разум ушёл… Сейчас полезу глану как он, zipfile устроен, но всё-таки хотелось немного подробнее.

ZAN
но это не решение проблемы, т.к. zip работать быстрее tar-а не будет.

Вот насколько мне помнится, скорость доспупа должна быть выше. Я бы хотел проверить.

ZAN
SQLite, PostgreSQL и прочие реляционные базы данных не нужны, как и язык SQL запросов в целом.

ZAN, ты, навреное, никогда не работал с Binary Large Object. Посредствам SQL находишь нужный объект, открываешь его и пишешь/читаешь как обычный файл, потом commit'ешь его или rollback'ешь и радуешься жизни.

ZAN
Cмотри лучше в сторону берклия - он быстрый + модель путь -> файл неплохо будет ложиться на архитектуру ключ -> значение, к тому же поддерживается стандартной поставкой питона.

Вот я опять же не въехал, как в него писать в “значение” файл и как его читать. Просто мне не очень навиться идея создания в пямяти объекта размером с гиг…
Если разбирусь с этим, то меня оно замечательно устроит. Даже больше скажу – это будет лучшим из возможных вариантов.

ZZZ
Просто мне не очень навиться идея создания в пямяти объекта размером с гиг

Минуточку, а почему ты решил, что в случае с BLOB будет по другому?

а це не підійде? http://www.hforge.org/itools

Lexander
Минуточку, а почему ты решил, что в случае с BLOB будет по другому?

Ну он вообще-то для этого и создан. Не знаю, как оно работает в SQLite, но вот в моём любимом PostgreSQL оно работает замечательно. Проверено. Правда на Си… :-)