[physfs] Using ZIP and GRP files
Ryan C. Gordon
icculus at clutteredmind.org
Sat May 24 00:26:07 EDT 2003
> I was gonna use it for tools purposes - I think it should be
> implemented because at least if it is there people can use it if they
There's nothing wrong with having them implemented, in fact, the question
comes up a lot, and usually in relation to game tool development.
Here's a basic rundown of issues that would need consideration:
1) Compression is expensive, but this is less of an issue in a tool; for a
game, it'd be _bad_ to write a zip at runtime.
2) You can't really compress on the fly, since any given file may be
written to, seeked around in, and written again.
3) You can't even really compress on file close, since you'd have to
rewrite the whole zipfile to accomodate the other contained files and
update the central directory.
So, basically, when opening a file for write, you'd have to cache the
entire thing in memory, uncompressed. If the file is closed, you still
need to cache it in case it's opened again (although, arguably, you could
risk compressing it at this point). When the write dir is changed (or
PHYSFS_deinit() is called, etc), you should check if any files in this zip
have been (re)written, and compress them, and proceed to rewrite the
A different approach would be to completely uncompress the zipfile to an
appropriate temporary location when it becomes the write dir, and then let
the platform drivers handle the newly unpacked physical files like that
temp location was really the write dir. When the zipfile ceases to be the
write dir, just zip up the temp directory and replace the original
archive. This makes the process less memory intensive and easier to manage
from the programmer's viewpoint, but causes other issues (orphaned files
laying around if there's a crash, write permissions, selecting a
temporary location in a cross-platform way, etc). This way could be
bootstrapped by calling an external "zip" program to recompress until a
real ZIP writer is implemented...not a trivial effort in itself, either.
Once a real writer is implemented, you wouldn't have to uncompress the
whole archive when setting the archive path, since you could just move the
existing compressed data to the new archive.
More information about the physfs