On Feb 1, 2023, at 11:44 AM, Fred Cisin via cctalk <cctalk@classiccmp.org> 
wrote:
> 
> On Wed, 1 Feb 2023, Zane Healy via cctalk wrote:
>> So far I’ve tackled one split zip.  I wasn’t having any luck with the 
>> version of PKZIP that I assume created this.  I copied the files into a 
>> directory, and did COPY FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP 
>> COMBINED.ZIP
> 
> THAT will give you a corrupted file!
> 
> Concatenated copy (COPY with '+') has a behavior that you need to take into 
> account.
> 
> PC/MS-DOS 1.00 kept track of the file size with a course granularity. 
> (logical sectors, not bytes) Therefore, PC/MS-DOS supported CTRL-Z as an end 
> of file character!
> (A legacy of CP/M)
> 
> When you cop a file, it copies the whole thing.  Any extraneous content after 
> EOF won't matter.
> 
> BUT!  When you concatenate files,
> COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP
> COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters!
> When copying text files, Concatenated COPY will trim off all content after 
> EOF!
> It is called "text mode".
> 
> You need to change your command to
> COPY /B  FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP
> to get "binary mode", so that it will copy ALL of each file, rather than just 
> to the "end of file character" of each!
> 
> Compare the final resulting file size of  COPY and COPY /B
> 
> --
> Grumpy Ol' Fred               ci...@xenosoft.com

I’m running the version of DOS that comes with DOSBOX-X (I think it’s 
FreeDOS?).  Checking COPY, and I’m not sure it supports /B, but it also doesn’t 
complain, the resulting combined ZIP is the same in both cases.  Turns out that 
I have three corrupted files in the fixed Zip, before fixing it there are a lot 
more.  That’s based on telling PKZIP to check the ZIP integrity. 

Zane



Reply via email to