If you add a file to an existing archive, you must add an entry to the directory structure and thus move all archive chunks in the file. It's better to store the directory information at the end of the archive, 'cause then you would only have to shift the directory structure which is most probably a lot smaller. Adding files to archives is the most common modification of archives, so optimizing the format to that operation is preferred I guess?

I'll actually be employing a smiliar concept as this in my resource files, but done a slightly different way. First of all, all my resource files (be it a texture, a 3D model, or a level) will be stored in the same file structure. The same chunk identifications will be common between all the different files. The file itself isn't indexed, it's just sequential access though. Anyway, chunks in my files will either be grouping, in which case they contain no data by themselves, or data chunks. In the case of grouping chunks, the data for that chunk is all stored in "child" chunks that are contained inside that chunk. You can't compress these ones. Data chunks however can be compressed. I would probably only compress large data chunks that contain things like geometric data, or texture data, but any data chunk could be compressed.

This system means I can traverse the structure of the file without decompressing anything. If I was after something in perticular, I can determine what I actually want, then decompress just that portion. It also allows new chunks to be added or removed easily, because the structure is unaffected by the compression.

I have one general chunk header, which at this time I think will be something like this:

-Chunk ID			;(int)-Chunk size/compression flag	;(int)	Compression flag	;bit 32	Chunk size		;bits 1-31-Chunk version			;(int)

I can use the upper bit of the size member to indicate if compression is in use, because it's quite unlikely I'll be needing a 4GB chunk anytime soon. The only relevant part of my file structure is the chunk header. Each chunk then has a fixed structure that defines its data members. This format has the main limitation however that it does not allow for repetition of data. If for some reason I want the same data to be referanced twice, I need to store it twice. I'll think this over more the closer I get to implementation, and decide if it's enough of a limitation to warrant desiging a more sophisticated method. This is the simplest, so it's the most attractive from that front.

Oh, and I should mention. I'll be using an implementation of LZ77 compression, so it's fairly straightforward, and I don't need any special information to be stored for each compressed chunk, I just have to know it's compressed.