> Perhaps surprisingly, the ZIP file puts the central directory - which lists the content of the ZIP file - at the end of the file

This is very common for archive files. It lets you easily append a file to the end of the archive (overwriting the directory) followed by the updated directory. If it were at the start, you’d have to rewrite the entire contents of the archive to grow the directory.

▲

flomo a day ago | parent | next [-]

> This is very common for archive files.

Maybe. But Unix types have always been all-in on tar. They love tar. They continue to use some form of tar to this day.

This was actually a 'cultural issue' back in the day, because Sun Java JAR files were just ZIPs. For good reason. But that wasn't the blessed holy unix archive format.

▲

yjftsjthsd-h a day ago | parent | prev | next [-]

I always assumed you could work around this by pre-allocating a large enough header space to hold a reasonable sized directory tree. You could even then append a supplementary directory if you run out of space and just stick a pointer in the first one. I'm pretty sure that's just reinventing an actual filesystem, but if it works...

▲

bell-cot a day ago | parent | next [-]

> ... pre-allocating a large enough header space to hold ...

Isn't the point of compression is to eliminate such wastes of space?

	▲	yjftsjthsd-h a day ago \| parent [-]
		It's a trade between size and speed. If you want fast lookup, it's not a waste.

▲

akoboldfrying a day ago | parent | prev | next [-]

Sure, this would also work. But it seems more complicated -- what would be the benefit?

	▲	yjftsjthsd-h a day ago \| parent [-]
		Losing the back half of the achieve doesn't lose your directory list. (Truth be told, I prefer the approach of sticking a copy on the front and back for redundancy, but I appreciate that that's a very specific tradeoff)

▲

LoganDark a day ago | parent | prev [-]

Isn't this basically FAT without the actual allocation table?

▲

ahefner a day ago | parent | prev | next [-]

Do you really need a central directory? The tar and cpio file formats basically append files serially with a small header preceeding each one, and for most use cases this is sufficient.

	▲	toast0 a day ago \| parent [-]
		You don't need one, but it's convenient for listing the files in the archive without having to scan through it.

▲

LoganDark a day ago | parent | prev [-]

I'm curious, is there a reason why you can't incrementally prepend to files? I haven't seen a filesystem that allows prepending to a file without rewriting the entire file. Is it just because it's not traditional, or is there any particular technical reason why it would be too expensive, or etc?

	▲	bell-cot a day ago \| parent \| next [-]
		In a world long accustomed to "append only" files, use cases would be relatively few. Vs. the folks creating and testing filesystems would have to do a whole lot of work to add that feature. Followed by the folks doing higher-level software, most of which which need to handle files being prepended to. In short - interesting idea, not worth the effort.
	▲	pestatije a day ago \| parent \| prev \| next [-]
		its a legacy from the tape-storage times
	▲	gjvc a day ago \| parent \| prev [-]
		the size of the prepended data would rarely be an exact number of blocks such that it became purely a metadata update (see also: inode small file optimisation), and thus you would have a small "hole" in the file between the new data and the existing data, which would have to be bookkept safely.