1 Feb
2023
1 Feb
'23
7:17 p.m.
On Feb 1, 2023, at 11:44 AM, Fred Cisin via cctalk <cctalk(a)classiccmp.org> wrote:
On Wed, 1 Feb 2023, Zane Healy via cctalk wrote:
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
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 cisin(a)xenosoft.com