| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Алгоритмы > Хранение фалов в одном |
| Автор: dershokus 9.11.2012, 12:41 |
| Здравствуйте. Стоит задача хранения многих файлов в одном (просто чтобы было не 1000 а 1 файл - для удобства). Так же нужно реализовать возможность добавления/удаления/редактирования. Как это лучше сделать? Я вижу несколько вариантов решения: 1. Так как сделано в zip архиве, но без сжатия. тоесть хранить header с размером файла (ну и атрибутами). Для быстрого поиска начала следующего файла нужно будет проходить от первого и прибавлять размер текущего файла чтобы наткнуться на следующий header. 2. Сделать индексный файл где будут храниться все имена и адрес начала файла, но тут получается, что будет 2 файла, а не один. Так же можно эти header'ы или index'ы хранить в начале(конце?) файла, но при каждом изменении придется сдвигать весь файл или индексы в конце. Может я чего-то не вижу? Есть идеи о улучшении метода? Писать буду на c/c++ хотя здесь это и совсем не важно... |
| Автор: Silent 9.11.2012, 12:58 |
| Возьми в качестве основы любую простую файловую систему, например FAT, и на ее основе делай свою структуру мега-файла |
| Автор: dershokus 9.11.2012, 13:06 |
| На сколько я понял в fat используется таблица кластеров(занят, свободен) которая по большому счету формируется на этапе форматирования. У меня размер хранилища файла динамический => сделать некую статическую таблицу кластеров не получится (нужно тоже динамическую). Или я что-то не понимаю? |
| Автор: Silent 9.11.2012, 13:08 |
| все правильно понимаешь, но в этом проблемы нет - делай ее тоже динамической. делаешь эту таблицу определенного размера, в последней ячейке - либо NULL, либо ссылка на следующую "таблицу кластеров" |
| Автор: Akina 9.11.2012, 13:15 |
| dershokus, используй "размыв" FAT. Т.е. хранилище у тебя прирастает блоками, каждый блок содержит 1 служебный сектор (настоятельно советую), 1 сектор FAT и сколько там нужно секторов. Скажем для 32-битной FAT это будет 128 кластеров, если кластер по 1 сектору, то 128 секторов, при размере сектора в 512 байт размер блока составит 65 кбайт. |
| Автор: Silent 9.11.2012, 13:23 |
| Хотя можно не изобретать велосипед самому, а воспользоваться готовыми - например, взять из virtualbox модули по работе с виртуальными винтами. Форматы vdi, vmdk и vhd используются давно, есть стандарты (http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf?src=vmdk, например), или, даже opensource-модули для работы с ними, например, qemu |
| Автор: dershokus 9.11.2012, 13:26 |
| Я извиняюсь за некоторую дубовость, но на вики читать о структуре FAT достаточно сложно %) Тупой вопрос: где хранится информация о файле? Тоесть имя и все прочее. На сколько я понимаю рядом с данными о файле? А что будет если отредактированный файл разростется и не будет вмещаться в чанк/блок? Конечно можно стереть его с предыдущего чанка и приделать еще один... |
| Автор: dershokus 9.11.2012, 13:30 |
| Silent, Ну велосипед конечно предпочтительней т.к. можно будет заточить под себя. Но вообще все выглядит интересно, главное чтобы поиск информации был еще быстрый. Попробую реализовать Добавлено через 4 минуты и 34 секунды baldina, Нет нет. Именно фалы, причем достаточно маленькие и с динамическим размером. Это не просто сериализация массива в файл (ну к примеру). |
| Автор: baldina 9.11.2012, 13:35 | ||
лучше вам таки взять готовую библиотеку)))))) нет, не рядом. имя файла - это его метаданные. сам файл про свое имя не знает, более того файл может иметь несколько имен (в одном или разных каталогах), и все они равноправны. Добавлено через 12 минут и 34 секунды http://www.ozon.ru/context/detail/id/2419365/ почитайте, там все подробно рассказано, есть код на C. |
| Автор: ksnk 9.11.2012, 15:03 |
| dershokus, А почему бы не взять tar? Каталог к тару формируется при первом обращении. В дальнейшем - храниться в памяти, как в обычной файловой системе. Новые 'файлы' дописываются в конец тара. Удаляемые файлы помечаются специальным флагом. Периодически, когда размер собственно файла становится на сколько-то больше, чем мог бы, производится "перепаковка" тара с выкидыванием удаленных. |
| Автор: dershokus 9.11.2012, 15:11 |
| Да, по большому счету задача выраждается к реализации tar или чего-то схожего. По всей видимости становится больше лабараторной, нежели прикладной Всем спасибо. |
| Автор: baldina 9.11.2012, 15:56 |
но tar и zip и т.п. уже изобретены, есть библиотеки |
| Автор: _Y_ 9.11.2012, 22:42 |
| Чтоба не разбивать таблицу на части, можно писать ее в конце файла. Поскольку таблица обновляется чаще, чем основное "тело данных", это даст некоторую выгоду ИМХО - при изменении размера таблицы не придется двигать данные. Если же само тело нужно удлиннить, переписывать придется только коротенькую таблицу. |