Составной файл

← →
Xerx (2004-06-24 04:41) [0]

Привет всем!
Вот появилась тут проблемка: нужно хранить кучу файлов в одном файле! Необходима обильная работа с внутренними файлами! Объясните как, либо укажите ссылку. Особо интересует УДАЛЕНИЕ файлов, с остальным все более-менее понятно.

← →
Fay © (2004-06-24 06:30) [1]

Заведи себе там маленький FAT...

← →
Reindeer Moss Eater © (2004-06-24 08:40) [2]

F1 + win32sdk + keyword "Structured Storage"

← →
Amoeba © (2004-06-24 13:09) [3]

Использовать такое стандартное средство Windows, как структурированные хранилища. В сети есть статья
http://www.comizdat.com/3/4/90/3571/3574

Рекомендую библиотеку классов и ф-й от Alex"а Konshin"а:
http://home.earthlink.net/~akonshin/delphi_ru.htm

← →
GuAV © (2004-06-24 13:20) [4]

а ещё есть компоненты - зиповалки.

← →
Amoeba © (2004-06-24 13:23) [5]

> GuAV © (24.06.04 13:20) [4]

Ну это через одно место...
Лучшее (и единственно правильное) решение задачи - структурированные хранилища.

← →
PVOzerski © (2004-06-24 13:44) [6]

Есть такая GNU-программа - tar называется...

← →
Amoeba © (2004-06-24 13:51) [7]

> Необходима обильная работа с внутренними файлами!

Со структурированными хранилищами это делается очень легко и быстро, в отличие от архиваторов.

← →
Amoeba © (2004-06-24 13:59) [8]

Есть еще вариант: Single File System от AidAim
http://www.aidaim.com/products/delphi.php#sfs

← →
Xerx © (2004-06-28 04:17) [9]

Ну спасибо, на день чтения!!!
А компоненты не пойдут, я пишу без VCL. Но всё равно спасибО!

← →
Xerx © (2004-06-28 04:29) [10]

Ну спасибо, на день чтения!!!
А компоненты не пойдут, я пишу без VCL. Но всё равно спасибО!

← →
y-soft © (2004-06-28 08:48) [11]

>Amoeba © (24.06.04 13:23) [5]

Лучшее (и единственно правильное) решение задачи - структурированные хранилища.

Насчет этого высказывания можно очень и очень поспорить. У структурированных хранилищ есть и недостатки:

1. Склонность к фрагментированию
2. Неэкономное использование дискового пространства при хранении маленьких "файлов" (под каждый поток выделяется не менее 4 kb, даже если записывается всего 1 байт)
3. Довольно низкая скорость доступа
4. Функции по сортировке и фильтрованию придется реализовывать самостоятельно
5. формат поддерживается только в Windows

Можно subj реализовать и иными способами:

1. Хранить все в однофайловой базе данных

Достоинства: высокая скорость доступа в современных СУБД, возможность выполнения запросов по любым критериям

Недостатки: должна быть установлена эта самая СУБД

2. Использовать XML

Достоинства: поддержка встроена в современные ОС, возможно выполнять фильтрацию и сортировку, межплатформенная совместимость

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

3. Написать собственную альтернативу :)

← →
X-Men (2004-06-28 08:54) [12]

Можно ещё сделать по принципу кэша Оперы. Правдо всё придётся писать руками.
PS SDK на их сайте(поиском)

← →
TUser © (2004-06-28 09:22) [13]

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

Можно организовать в виде страниц/сегментом. При удалении память реструктурировать не надо.

← →
Xerx © (2004-06-30 04:18) [14]

Смотрел я Storage, так там в примере больно часто ошибки вылезают. И проблемы с сохранением русского текста. Так что я пока отдам на хранение Storage свою самую нелюбимую книгу на французском - понятней не станет, а только в размере уменьшится! В общем, что-то не то.
Насчет XMl - ни в какие рамки: у меня большинство файлов будут бинарными (~95%).
Оперу я гляну...
А нельзя ли поподробнее по СУБД?

← →
Xerx © (2004-06-30 04:20) [15]

>TUser
>Если свлаить все в один файл ручками, то надо будет создать свою >таблицу наподобии фата, где хранить инфу о файлах. При удалении >первоначально старать из таблицы, переодически реструктурировать.
>Можно организовать в виде страниц/сегментом. При удалении память >реструктурировать не надо.

А нельзя ли поподробнее...

← →
y-soft © (2004-06-30 08:08) [16]

>Xerx © (30.06.04 04:18) [14]

А нельзя ли поподробнее по СУБД?

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

CREATE TABLE FILE_STORAGE ( ID INTEGER NOT NULL, /*Уник. идент. файла*/ FILE_NAME VARCHAR(260) NOT NULL, /*Имя файла*/ PARENT INTEGER, /*Уник. идент. родительской директории*/ ATTRIBUTES INTEGER, /*Атрибуты файла*/ FILE_AGE TIMESTAMP, /*Дата создания файла*/ DATA BLOB SUBTYPE 0, /*Непосредственно данные*/ PRIMARY KEY (ID)); ALTER TABLE FILE_STORAGE ADD FOREGN KEY (PARENT) REFERENCES FILE_STORAGE ON UPDATE CASCADE ON DELETE CASCADE ;

При необходимости можно добавить и другие поля (дата последнего изменения, комментарии и пр.)

Поле FILE_NAME лучше проиндексировать, но лучше вообще создать уникальный индекс по связке (PARENT, FILE_NAME) (чтобы обеспечить уникальность имен файлов в директории)

Для корневой директории поле PARENT равно NULL

С помощью SQL элементарно реализуются аналоги команд Dir, Deltree, Delete и т.д.

Можно организовать структуру БД и иначе - на http://ibase.ru, помнится, была статья по хранению древовидных структур

IMHO главные достоинства такого подхода: автоматически отслеживается целостность ссылок, легко решаются проблемы конфликтов совместного доступа и просто делается дефрагментация...

← →
TUser © (2004-06-30 11:44) [17]

> А нельзя ли поподробнее...

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

← →
Amoeba © (2004-06-30 13:04) [18]

А может все же стоит попробовать: Single File System от AidAim
http://www.aidaim.com/products/delphi.php#sfs

Это не компонент, а 2 класса - потомка TObject

← →
TUser © (2004-06-30 13:47) [19]

> А может все же стоит попробовать

Безусловно. Написание своей собственной файловой системы - не самая простая задача. Не ось, коненчо, но все-таки :) Если есть готовые решения, лучше использовать их.

> При использовании "фата" нао хранить в начале файла таблицу - где начинается и где заканчивается каждый файл.

На мой взгляд гораздо удобнее хранить таблицу в КОНЦЕ файла. Представь ситуацию, когда нужно ДОБАВИТЬ новый файл. Таблица разростается и нужно перелопачивать ВЕСЬ ФАЙЛ ЗАНОВО! А если таблица в конце, то сохраняю новый файл поверх нее (ну и далее), и в конце дописываю новую таблицу!

Это моя реализация этой темы. Ничего лучше, чем натисать свое я не нашел.

Single File System от AidAim
http://www.aidaim.com/products/delphi.php#sfs
Использование предельно просто и прозрачно. Это готовое и выполенное на профессиональном уровне решение твоей задачи. Стоит ли изобретать велосипед? Не факт, что колеса у него получатся достаточно круглыми.

> Amoeba [21]
прежде чем так навязчиво советовать его, следовало бы заглянуть сюда - http://www.aidaim.com/order/purchase.php#SFS
не думаю, что кто-то захочет отдавать 95 - 195 уёв...

Во-первых, не все так плохо - бесплатная версия полнофункциональная (сам использовал), только выбрасывается т.н. NagScreen при запуске программы. Но можно скачать на халяву с китайского варезного сайта (там можно найти много чего!) нормальную с исходниками:
http://www2.0zones.com:808/SoftDown.asp?ID=10612
Сайт доступен со второй половины дня по московскому времени.
Только Hepl придется брать от бесплатной с сайта AidAim.
Так что нет необходимости тратить гроши.

← →
Serginio666 (2004-07-02 17:23) [24]

Посмотри http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
там пример хранения разных данных в том числе и блоб.
Причем размер блоба можешь настрооить сам

И правда, проще всего самому ручками все сделать.

← →
Fay (2004-07-10 05:07) [26]

>Amoeba
>Во-первых, не все так плохо - бесплатная версия полнофункциональная ...

Действительно, удобно! Но ничего не выбрасывает! И это по прежнему компонент, который в DLL занимает 389 Кб. Конечно, терпимо, но ЖЕЛАТЕЛЬНО БЕЗ VCL!!!

← →
Asinus (2004-07-12 07:15) [28]

> ЖЕЛАТЕЛЬНО БЕЗ VCL!!!

Тогда имеет смысл обратить внимание на Structured Storages. У А.Коншина есть удобная библиотека классов-оберток (не компоненты, исходники) вокруг API ф-й.
http://home.earthlink.net/~akonshin/delphi_ru.htm

Составной файл Найти похожие ветки