> recently we had a particularly bad case: a customer sent us an approximately 1 GB project file which was corrupt, for a game already published to Steam, which they'd spent months working on. They told us all their backups were corrupt too... Predictably, WinRAR's repair tool produced a 1 GB ZIP file that contained nothing.
Recovering Corrupt Zip Files (construct.net)
43 pointsby AshleysBrain4 days ago20 comments
dotancohen 8 hours ago
BatFastard 7 hours ago
As the old saying goes, an untested backup is a non backup.
toast0 7 hours ago
There's tons of marginal hardware out there, and game developers sometimes push hardware pretty hard and may run early drivers, etc.
matja 6 hours ago
The more popular your software is, the more likely you'll get bug reports from people with just bad hardware. I know a few applications now that perform a simple memory/CPU test when sending a bug report and reject those that are basically impossible.
E.g.: 10% of Firefox crashes are caused by bitflips : https://news.ycombinator.com/item?id=47252971
ranger_danger 4 hours ago
Firefox was the only program that was crashing on my "Vmin Shift Instability" bugged CPU. Before I even knew what the culprit was, I filed a bug report with Firefox and the first question they asked me was if my CPU was a Raptor Lake (it was).
akoboldfrying 3 hours ago
This is right. There's a reason people squat domain names that differ from well-known ones by a single bit flip. Think of how many old, shitty phones there are in the world, built using the cheapest available components and running in someone's crumb-filled, humid pocket right next to their magnetic key fob thing.
CrendKing 7 hours ago
I just tested. 7-Zip is already doing exactly what the author's recovery tool does: if I delete the metadata at the end of the file, it still can open and extract files, while complaining about the harmless "Unexepcet end of data". Further, even if I delete the actual content of the last file, it still can show the directory structure, it just can't extract data of the last file.
cmovq 5 hours ago
> 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.
yjftsjthsd-h 4 hours ago
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...
LoganDark 3 hours ago
Isn't this basically FAT without the actual allocation table?
akoboldfrying 2 hours ago
Sure, this would also work. But it seems more complicated -- what would be the benefit?
yjftsjthsd-h an hour ago
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)
bell-cot 2 hours ago
> ... pre-allocating a large enough header space to hold ...
Isn't the point of compression is to eliminate such wastes of space?
yjftsjthsd-h an hour ago
It's a trade between size and speed. If you want fast lookup, it's not a waste.
LoganDark 3 hours ago
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 2 hours ago
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.
ahefner an hour ago
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 32 minutes ago
You don't need one, but it's convenient for listing the files in the archive without having to scan through it.
andrewshadura 7 hours ago
It seems technically possible to create an append-only ZIP writer that would only add files at the end of a ZIP archive behind the existing central directory, and then write a new central directory including the new files (and excluding the deleted files). That might make it more difficult to irrecoverably damage the archive as most of it contents will likely be preserved after e.g. an abrupt loss of power.
tyingq 5 hours ago
-g
--grow