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
