29 Jan
2023
29 Jan
'23
9:37 p.m.
Some of the floppies I’m recovering data look to be either a multi-part ZIP file, or
something. Was this a separate product from PKZIP? I’m not sure if I have a copy of
PKZIP in the stuff I’ve recovered thus far. I’ve not pulled them into DOSBOX to try and
restore them, so far I’ve just tried to use Stuffit-Expander. Part of the problem is
every file has the same name, just on different floppies.
Zane
30 Jan
30 Jan
7 a.m.
On Sun, Jan 29, 2023, 9:37 PM Zane Healy via cctalk <cctalk(a)classiccmp.org
wrote:
Some of the floppies I’m recovering data look to be
either a multi-part
ZIP file, or something. Was this a separate product from PKZIP? I’m not
sure if I have a copy of PKZIP in the stuff I’ve recovered thus far. I’ve
not pulled them into DOSBOX to try and restore them, so far I’ve just tried
to use Stuffit-Expander. Part of the problem is every file has the same
name, just on different floppies.
Zane,
I vaguely remember this feature of PKZIP. It's called disk spanning.
https://superuser.com/questions/260067/restoring-ancient-zip-file-spanning-…
Sellam
8:05 a.m.
Pkunzip would automatically prompt you to insert disk 2, etc for spanned
disks. I believe a workaround was copying the files to a local directory
and combining them (in dos copy zip1.zip+zip2.zip full.zip). Not sure how
current archive products react to spanned disks or if it was standardized.
On Mon, Jan 30, 2023, 9:01 AM Sellam Abraham via cctalk <
cctalk(a)classiccmp.org> wrote:
On Sun, Jan 29, 2023, 9:37 PM Zane Healy via cctalk
<cctalk(a)classiccmp.org
wrote:
I vaguely remember this feature of PKZIP. It's called disk spanning.
https://superuser.com/questions/260067/restoring-ancient-zip-file-spanning-…
Sellam
Some of the floppies I’m recovering data look to
be either a multi-part
ZIP file, or something. Was this a separate product from PKZIP? Part
of the problem is every file has the same
> name, just on different floppies.
31 Jan
31 Jan
1:26 p.m.
On Jan 29, 2023, at 9:37 PM, Zane Healy via cctalk <cctalk(a)classiccmp.org> wrote:
Some of the floppies I’m recovering data look to be either a multi-part ZIP file, or
something. Was this a separate product from PKZIP? I’m not sure if I have a copy of
PKZIP in the stuff I’ve recovered thus far. I’ve not pulled them into DOSBOX to try and
restore them, so far I’ve just tried to use Stuffit-Expander. Part of the problem is
every file has the same name, just on different floppies.
Info-ZIP still supports "split" archives, and spanned archives can be converted
to split archives by renaming them to the appropriate extension. From the man page:
zip version 3.0 and later can create split archives. A split archive is a standard zip
archive split over multiple files. (Note that split archives are not just archives split
in to pieces, as the offsets of entries are now based on the start of each split.
Concatenating the pieces together will invalidate these offsets, but unzip can usually
deal with it. zip will usually refuse to process such a spliced archive unless the -FF
fix option is used to fix the offsets.)
One use of split archives is storing a large archive on multiple removable media. For a
split archive with 20 split files the files are typically named (replace ARCHIVE with the
name of your archive) ARCHIVE.z01, ARCHIVE.z02, ..., ARCHIVE.z19, ARCHIVE.zip. Note that
the last file is the .zip file. In contrast, spanned archives are the original multi-disk
archive generally requiring floppy disks and using volume labels to store disk numbers.
zip supports split archives but not spanned archives, though a procedure exists for
converting split archives of the right size to spanned archives. The reverse is also
true, where each file of a spanned archive can be copied in order to files with the above
names to create a split archive.
A split archive with missing split files can be fixed using -F if you have the last split
of the archive (the .zip file). If this file is missing, you must use -FF to fix the
archive, which will prompt you for the splits you have.
David.
1 Feb
1 Feb
8:18 a.m.
New subject: [SPAM] Re: PKBACK Floppies?
On Jan 31, 2023, at 1:26 PM, David Glover-Aoki via
cctalk <cctalk(a)classiccmp.org> wrote:
On Jan 29, 2023, at 9:37 PM, Zane Healy via cctalk <cctalk(a)classiccmp.org> 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 still wasn’t working, as the file was corrupt, but I managed to use PKZIPFIX to fix
it, and then I could unzip it. The info above will definitely help, especially with
regards to the ZIPs missing the first part.
Slowly I’m recovering my old DOS system.
Zane
Some of the floppies I’m recovering data look to be either a multi-part ZIP file, or
something. Was this a separate product from PKZIP? I’m not sure if I have a copy of
PKZIP in the stuff I’ve recovered thus far. I’ve not pulled them into DOSBOX to try and
restore them, so far I’ve just tried to use Stuffit-Expander. Part of the problem is
every file has the same name, just on different floppies.
Info-ZIP still supports "split" archives, and spanned archives can be converted
to split archives by renaming them to the appropriate extension. From the man page:
zip version 3.0 and later can create split archives. A split archive is a standard zip
archive split over multiple files. (Note that split archives are not just archives split
in to pieces, as the offsets of entries are now based on the start of each split.
Concatenating the pieces together will invalidate these offsets, but unzip can usually
deal with it. zip will usually refuse to process such a spliced archive unless the -FF
fix option is used to fix the offsets.)
One use of split archives is storing a large archive on multiple removable media. For a
split archive with 20 split files the files are typically named (replace ARCHIVE with the
name of your archive) ARCHIVE.z01, ARCHIVE.z02, ..., ARCHIVE.z19, ARCHIVE.zip. Note that
the last file is the .zip file. In contrast, spanned archives are the original multi-disk
archive generally requiring floppy disks and using volume labels to store disk numbers.
zip supports split archives but not spanned archives, though a procedure exists for
converting split archives of the right size to spanned archives. The reverse is also
true, where each file of a spanned archive can be copied in order to files with the above
names to create a split archive.
A split archive with missing split files can be fixed using -F if you have the last split
of the archive (the .zip file). If this file is missing, you must use -FF to fix the
archive, which will prompt you for the splits you have.
David. 
11:44 a.m.
New subject: [SPAM] Re: PKBACK Floppies?
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 cisin(a)xenosoft.com
11:58 a.m.
New subject: [SPAM] Re: PKBACK Floppies?
On Wed, Feb 1, 2023 at 11:45 AM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
On Wed, 1 Feb 2023, Zane Healy via cctalk wrote:
Excellent knowledge transfer, Fred. That is what makes this list great.
Sellam
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
7:38 p.m.
New subject: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
On Feb 1, 2023, at 11:59 AM, Sellam Abraham via cctalk <cctalk(a)classiccmp.org>
wrote:
On Wed, Feb 1, 2023 at 11:45 AM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
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
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 cisin(a)xenosoft.com
8:02 p.m.
New subject: [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 cisin(a)xenosoft.com
7:17 p.m.
New subject: [SPAM] Re: [SPAM] Re: PKBACK Floppies?
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
7:38 p.m.
New subject: [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 cisin(a)xenosoft.com
442
days inactive
445
days old
10 comments
5 participants
participants (5)
-
David Glover-Aoki -
Fred Cisin -
John Herron -
Sellam Abraham -
Zane Healy