[cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: You have that right Sellam, the more that I look into this, based on Fred’s info, I think that I need to get MS-DOS running under DOSBOX-X. Probably worthwhile. Although the truncation of file content after EOF during concatenation is somewhat esoteric. There may be plenty of other things to check out. Are you using the correct version of PKZIP? I'm wondering how well PKZIP handles features that were added to PKZIP in versions newer than itself. Ideally, PKZIP should include metadata in files, including version number, to let you know whether it's a suitable version for a given file, . . . -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
On Feb 1, 2023, at 11:59 AM, Sellam Abraham via cctalk wrote: > > On Wed, Feb 1, 2023 at 11:45 AM Fred Cisin via cctalk > 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 > > > Excellent knowledge transfer, Fred. That is what makes this list great. > > Sellam You have that right Sellam, the more that I look into this, based on Fred’s info, I think that I need to get MS-DOS running under DOSBOX-X. Zane
[cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
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 copy 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
On Wed, 1 Feb 2023, Zane Healy 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.
If you get a convenient chance, try COPY /A ...+...+... ...
/A ("ASCII" or text mode) is the default in PC/MS-DOS, where CTRL-Z, and
any padding/junk after the EOF (CTRL-Z) character in the files in the
middle is truncated. That is so that when you concatenate text files, you
don't leave EOFs and sector/record padding in the middle.
If /A gives the same as /B and the same as no switch, then either your
version does not have that "feature", OR there are no CTRL-Z's (1Ah)
anywhere in the middle files!
If /A gives a shorter result, stay away from it, but that would mean that
/B is the default in your version.
--
Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
On Feb 1, 2023, at 11:44 AM, Fred Cisin via cctalk 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
