Zip – How not to design a file format
The author is missing an obvious point that computing was way too different at the time the format was designed.<p>You couldn&#x27;t do a &quot;find XXX | grep YYY | zip&quot; pipeline; you would instead often add files to an archive one-by-one. So the format consists of appendable records sharing the same structure, and adding new files is simply a matter of appending records to the end.<p>Now sometimes you would want to quickly locate and extract just one file out of the entire archive, and scanning the entire archive would be ridiculously slow on a system with &lt;1MB&#x2F;s throughput a some kilobytes of RAM. Hence, the central directory at the end of the archive.<p>Some other time, the power would go down while you are appending to the archive, or a bad block would pop up on your HDD, hence redundancy between the central directory and the records.<p>Also, writing archivers back then was very different from what we do now. There were no unit tests, no abstraction layers, and very limited debuggers. Software was hand-coded in assembly, and adding an extra field or a check here or there was much less trivial than it is now.<p>You can always find something that was designed under completely different constraints and call it a bad design. But in reality it only shows that the author hasn&#x27;t done enough research on the topic.