.zip files specify the compressor used for each file, one of which is no compression. You have to explicitly tell it to produce such a suboptimal result but it

.zip files specify the compressor used for each file, one of which is no compression. You have to explicitly tell it to produce such a suboptimal result but it can be done. Going back to the 90s--I was using .zip files as a container to keep all files in an order together. As time went on it the requirements included updating some of those files *in a shared access environment*. The workflow didn't permit two people to be updating the *same* file, but simply rebuilding the file on update was not permissible for concurrency reasons (nor was it permissible for speed reasons--I was state-saving each item checked off on a screen.) Solution: The files which could be updated in use were forced to no compression. I then wrote my own code which read the header and got an offset within the .zip that was the body of the file. I then treated it as a simple record-based file with that offset and wrote my changes. The CRCs were recalculated and written if the user left the screen, if the user crashed out (this was the DOS era and the machines were on a factory floor) the file would be reported as corrupt but would actually be intact. My program didn't check the CRC and would perfectly happily handle the situation. Ideal? No. The best that was realistically possible at the time, I believe so.