[softwarelist] Re: Bad CRCs in ZIPs
- From: "J.G.Harston" <jgh@xxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Thu, 03 Jan 2019 11:34:34 +0000
David Pilling wrote:
Actually corrupted or just the CRC, or just when read on RISC OS. If
it is actually corrupt then presumably the blame lies with WinRAR.
Testing on WinRAR gives no errors. Copying the copied file back to
Windows and testing on WinRAR gives an error. Loading a text file
from within the error'd ZIP shows the text going wrong where the
bitstream changes.
Which raises the question how bad is the corruption.
I copied them over the network and a diff showed three bytes in 330K+
with errors:
Should be:
:01:00F38C:00:43:3D
:01:014FC2:00:00:EE
:01:0187B6:00:9E:24
:00:000000:00:00
Errored:
:01:00F38C:00:DF:A1
:01:014FC2:00:19:D5
:01:0187B6:00:1E:A4
:00:000000:00:00
I think it's been random chance that it's ended up in the middle of
a ZIP within the ZIP. I think tweeking my network speed down a smidge
will fix that.
Zips in zips (or archives in archives) present problems for SparkFS
because it means the filing system has to be re-entrant, which latter
versions were.
I normally just treat all the files in a ZIP as files and drag them
out before doing anything with them, such as opening ZIPs from within
a ZIP. I'm normally only copying that direction when I've had to do
some RISC OSy updates on a non-RISC OS system, as I was doing over
Christmas while fighting with GitHub.
It would be useful if the SparkPlug 'Test' button wasn't greyed out
(have I accidently installed the free version, and that's a paid-for
function?), and/or the SparkFS 'Test' button did a CRC test.
--
J.G.Harston - jgh@xxxxxxxx - mdfs.net/jgh
To unsubscribe or subscribe goto:
//www.freelists.org/list/davidpilling
Other related posts:
