Multipart UUdecoding error

[RodFern]

Whenever I try do UUdecode a multipart uuncoded file I get this message:

"ERROR: premature end of file! If this is a multipart encoded file, the parts MUST be numbered like this: name01.uue, name02.uue, ..."

I even renamed files accordinly (name01, name02, name03...) but there is no way to get Total Commander to decode the file correctly.
As an example, I can decode this file (dj1bin.zoo) properly from the multipart text files sent the first time djgcc was released using other decoding programs, but I can't get it to be uuncoded using Total Commander.


...
Archive-name: dj1bin/part01

This is the first of many parts of gcc and g++ for DOS running on 386
and 486 machines. It doesn't run on any of the smaller machines, nor
will it, since the hardware is just not there for 32 bit arithmetic. It
will run integer programs without a 387, but will not even compile a
program which uses float (including constants). I've been trying it and
while it's useful, it is not totally bug free yet, so there will
probably be an update in a month or so based on user's reports.
...[
Checksums obtained with the 4.3BSD "sum" or System V "sum -r" command.

checksum size (bytes) file (between BEGIN--cut and END--cut lines)
30889 46273 part01
59403 46314 part02
50724 46314 part03
47807 46314 part04
25087 46314 part05
29107 46314 part06
54518 46314 part07
48492 46314 part08
11343 46314 part09
17288 46314 part10
35810 46314 part11
63207 46314 part12
20144 46314 part13
26901 46314 part14
38447 46314 part15
45076 46314 part16
14524 46314 part17
8102 46314 part18
19602 46314 part19
31318 46314 part20
2170 46314 part21
52815 46314 part22
53512 46314 part23
47295 46314 part24
4790 46314 part25
49897 46314 part26
34832 46314 part27
219 46314 part28
11610 46314 part29
30418 46314 part30
18726 46314 part31
21147 46314 part32
16713 46314 part33
22847 46314 part34
10009 46314 part35
59957 42662 part36

checksum size (bytes) file
39032 1207440 dj1bin.zoo

]

dj1bin part01/36
BEGIN--cut here--cut here
begin 644 dj1bin.zoo
...


The only way I've manage to decode it with TC was joining all the files and deleting everething between "END--cut here--cut here" and "BEGIN--cut here--cut here". making it a one part uuencoded file (so what's the point of having a multipart file?).

Sorry for the "engrish".

[ghisler(Author)]

Just use menu Files - Encode files and set the number of lines or bytes per file to see how a multi-part uue archive would look like:
The first file starts with
begin 644 filename.ext
M<base64 code>

The other parts start directly with
M<base64 code>

The last file ends with something like this:
end
sum -r/size 9143/71264

How do your files look like? Is each of them a separate uuencoded file with starts with begin?

[RodFern]

Well, sort of.

The files I tried to decode can be found here
Yeah, files sent over usenet (comp.binaries.ibm.pc) in 1991. It has been some time ago...

They do have that "begin 644 filename/M<base64 code>" part, but with some text before, like this:

First file:
[blahblahblah, some text]
dj1bin part01/36
BEGIN--cut here--cut here
begin 644 dj1bin.zoo
M<base64 code>
END--cut here--cut here

And so on, until last file:

[blahblahblah, some text]
dj1bin part36/36
BEGIN--cut here--cut here
M<base64 code>
`
end
END--cut here--cut here

If I strip out all the blahblahblah leaving only the encoded part between those "cut here--cut here" text, TC does manage to decode the file.

If memory serves me well I used to decode those files directly at the time, without the need to cut off the message part, and I've managed to decode them sucssefully with other decoding tools.

Anyway, thank you for your answer. I realized those files are not on the format TC expects. It is not a bug at all, TC does what it is supposed to do, not what I assumed it would do based on what I expected.

Maybe a future feature? Not that many people these days still decodes uuencoded files sent over usenet like 30 years ago, but one never knows...

[ghisler(Author)]

Indeed that's not a normal multi-part uue file. It's 36 separate files, but the headers are unusual too
BEGIN--cut here--cut here
instead of
begin 644 filename.ext
and each file has its own end.