Napadá mě nechat soubory i přes chybu a zkusit několikrát spočítat ten součet (pokud se na několik pokusů neshodne dá se na leccos usuzovat) a porovnat s původním, prostě podívat se, jestli se liší jen trochu nebo hodně.
Dále ještě před rozbalením spočítat součet toho archivu tam, kde funguje (jestli CRC32 nebo jiný je lhostejné), a potom ho spočítat tam, kde nefunguje. Pokud budou odlišné, neni moc co řešit (teda zase jen se podívat, jakým způsobem se liší).

Mě tohleto dělal jeden počítač zejména (tedy spíš jen) se soubory přenášenými po síti. Malé soubory byly v pohodě, když nevyšlo porovnání, soubor jsem smazal a nanejvýš napotřetí se to povedlo. Velké soubory jsem dělil a jednotlivým dílům jsem počítal CRC nebo MD5 a opět se to podařilo na poněkolikáté (nebo když mi došla trpělivost, hodil jsem soubor na flešku a přenesl takto). Zajímavé bylo, že se to stávalo právě jen při přenosu po síti, myslím, že jsem to dosud nevyřešil ale naučil jsem se s tím žít.
Ještě mám takovou historickou vzpomínku, stávalo se mi před tak 15-20 lety na jednom PC, že se vyskytovaly takové chyby. Zmizely když jsem vyměnil kšandu IDE. Měl jsem do té doby pocit (a nezbavil jsem se ho) že přenosy po rozhraní IDE jsou také chráněné nějakým redundantním kódem (minimálně paritou), takže mi to připadalo nevysvětlitelné, že vadná kšanda způsobí vadná data (ne že by byla vadná nějak moc, když se soubory porovnaly, lišil se nějaký bit, jen jeden což by právě parita měla odhalit). Ale to samé mi přijde nevysvětlitelné na síti, kde jsou data zcela jistě chráněná, protože na takovém přenosovém médiu se už z principu s výskytem chyb musí počítat.