If you give us a specific scenario, we'll be able to answer more specifically. Do you know the size of any of the blocks or any other characteristics about the blocks like how they start or end?

would it be better to keep data and the contents seperate but change the data size to a file offset. the size of the entry can be found from reading in the offset of the next block and subtracting them. If your at the end of the file, just use the filelength(f) to get the file size and subtract from that.

eg.
Index file
==========
Block_A 0
Block_B 2142144
Block_C 2297006


data file
=========
<data>
<data>
<data>

size of block b = 2297006 - 2142144 = 154862


that way you can have the Index file completely in memory and quickly search for the bit you need to delete. When you find the block you have the file offset and size of the data to remove. You can even sort these in alphabetical order and use a fast searching algorithm to improve searching speed further.

the index file would be rigid in its structure eg.

an array of..

struct INDEX_ENTRY {
char Name[28];
DWORD offset;
}; // 32 Bytes per structure.

so by getting the filelength of the Index file and dividing it by 32 will give you the number of entries so you can allocate an array to hold it in memory. You could then modify this index in memory (remove/add entries etc) and then save it to the index file again when finished.

you can also load objects quite quickly on demand (if you need to) as you can jump to the data you need quickly. reading through large files and searching can be slow as read functions are slow to complete. Best know what you want and go straight in and get it.

Id software used to (may still do, i dont know) keep data in pak files and have an index at the end of the file. The very first DWORD of the file would be the offset to this index. This isn't very easy to update though so i suggest keeping the index and data files seperate.

hope that helps

[Edited by - jrmcv on November 29, 2006 8:43:53 AM]