3 ms·

I believe the footer-only format was more about being able to make modifications by only appending to the zip file and not having to rewrite/shift any data.

canucker2016 4y ago
...the central directory needs to be shifted by the amount of the new compressed data + local directory header. But that's a lot less than if the central directory was at the beginning and the code had to grow the central directory and shift ALL the compressed data + local directory headers down.
- ladberg 4y ago
  Yeah that might be the ideal way to do it, but technically you could just append the new entries and new central directory without even removing the old one. I'm not entirely sure what storage system that would make sense on, but presumably there was one back in the day.
  - canucker2016 4y ago
    3.5" floppies - 800K-1.44MB, small and slow. Better than cassette tapes though...
    - cesarb 4y ago
      > 3.5" floppies - 800K-1.44MB, small and slow. I feel like a lot of people in this thread are missing a crucial part of the historical context: ZIP files can be split. That is, a single ZIP file can span more than one floppy disk. The entry for each compressed file in the central directory, which is always on the last floppy disk, has a field which says in which disk the compressed file can be found. If you had a multi-disk ZIP file, and wanted to extract a single file from it, you inserted the last disk, pointed the unpacking software at it, and it would tell you which disk(s) to insert (in sequence) to extract that file. A lot of the strange decisions of the ZIP file format make sense if you think about that use case: you have a directory full of files, which you want to compress into a set of floppy disks; and once you have that set of floppy disks, you want to extract a subset of the compressed files. You also want to be able to extract the undamaged files even when the last floppy disk (with the central directory) is damaged.

canucker2016 4y ago

...the central directory needs to be shifted by the amount of the new compressed data + local directory header. But that's a lot less than if the central directory was at the beginning and the code had to grow the central directory and shift ALL the compressed data + local directory headers down.

ladberg 4y ago
Yeah that might be the ideal way to do it, but technically you could just append the new entries and new central directory without even removing the old one. I'm not entirely sure what storage system that would make sense on, but presumably there was one back in the day.
- canucker2016 4y ago
  3.5" floppies - 800K-1.44MB, small and slow. Better than cassette tapes though...
  - cesarb 4y ago
    > 3.5" floppies - 800K-1.44MB, small and slow. I feel like a lot of people in this thread are missing a crucial part of the historical context: ZIP files can be split. That is, a single ZIP file can span more than one floppy disk. The entry for each compressed file in the central directory, which is always on the last floppy disk, has a field which says in which disk the compressed file can be found. If you had a multi-disk ZIP file, and wanted to extract a single file from it, you inserted the last disk, pointed the unpacking software at it, and it would tell you which disk(s) to insert (in sequence) to extract that file. A lot of the strange decisions of the ZIP file format make sense if you think about that use case: you have a directory full of files, which you want to compress into a set of floppy disks; and once you have that set of floppy disks, you want to extract a subset of the compressed files. You also want to be able to extract the undamaged files even when the last floppy disk (with the central directory) is damaged.