Здравствуйте. Стоит задача хранения многих файлов в одном (просто чтобы было не 1000 а 1 файл - для удобства). Так же нужно реализовать возможность добавления/удаления/редактирования. Как это лучше сделать?
 Я вижу несколько вариантов решения:

1. Так как сделано в zip архиве,  но без сжатия. тоесть хранить header с размером файла (ну и атрибутами). Для быстрого поиска начала следующего файла нужно будет проходить от первого и прибавлять размер текущего файла чтобы наткнуться на следующий header.
2. Сделать индексный файл где будут храниться все имена и адрес начала файла, но тут получается, что будет 2 файла, а не один. Так же можно эти header'ы или index'ы хранить в начале(конце?) файла, но при каждом изменении придется сдвигать весь файл или индексы в конце.

Может я чего-то не вижу? Есть идеи о улучшении метода?
Писать буду на c/c++ хотя здесь это и совсем не важно...

Возьми в качестве основы любую простую файловую систему, например FAT, и на ее основе делай свою структуру мега-файла

На сколько я понял в fat используется таблица кластеров(занят, свободен) которая по большому счету формируется на этапе форматирования. У меня размер хранилища файла динамический => сделать некую статическую таблицу кластеров не получится (нужно тоже динамическую).
Или я что-то не понимаю?

все правильно понимаешь, но в этом проблемы нет - делай ее тоже динамической. делаешь эту таблицу определенного размера, в последней ячейке - либо NULL, либо ссылка на следующую "таблицу кластеров"

dershokus, используй "размыв" FAT. 
Т.е. хранилище у тебя прирастает блоками, каждый блок содержит 1 служебный сектор (настоятельно советую), 1 сектор FAT и сколько там нужно секторов. Скажем для 32-битной FAT это будет 128 кластеров, если кластер по 1 сектору, то 128 секторов, при размере сектора в 512 байт размер блока составит 65 кбайт.

Хотя можно не изобретать велосипед самому, а воспользоваться готовыми - например, взять из virtualbox модули по работе с виртуальными винтами. Форматы vdi, vmdk и vhd используются давно, есть стандарты (vmdk, например), или, даже opensource-модули для работы с ними, например, qemu

Я извиняюсь за некоторую дубовость, но на вики читать о структуре FAT достаточно сложно %)
Тупой вопрос: где хранится информация о файле? Тоесть имя и все прочее. На сколько я понимаю рядом с данными о файле?
А что будет если отредактированный файл разростется и не будет вмещаться в чанк/блок? Конечно можно стереть его с предыдущего чанка и приделать еще один... 

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

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

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

Добавлено через 4 минуты и 34 секунды
baldina, Нет нет. Именно фалы, причем достаточно маленькие и с динамическим размером. Это не просто сериализация массива в файл (ну к примеру).

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

Добавлено через 12 минут и 34 секунды
это почитайте, там все подробно рассказано, есть код на C. 

dershokus, А почему бы не взять tar? 
Каталог к тару формируется при первом обращении. В дальнейшем - храниться в памяти, как в обычной файловой системе. Новые 'файлы'  дописываются в конец тара. Удаляемые файлы помечаются специальным флагом. Периодически, когда размер собственно файла становится на сколько-то больше, чем мог бы, производится "перепаковка" тара с выкидыванием удаленных. 

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

но tar и zip и т.п. уже изобретены, есть библиотеки

Чтоба не разбивать таблицу на части, можно писать ее в конце файла. Поскольку таблица обновляется чаще, чем основное "тело данных", это даст некоторую выгоду ИМХО - при изменении размера таблицы не придется двигать данные. Если же само тело нужно удлиннить, переписывать придется только коротенькую таблицу.