[emn13]

Mike's responses could have been better, but in the correspondence I see no guarantee that the files will be presented in order, or with the same file names, or in an otherwise empty directory.

That sounds close to cheating, but I think it's exactly in the spirit of both the original challenge by Mike and the response by Patrick. After all, the original challenge didn't mention multiple files (so it's not surprising that this limitation isn't mentioned), and the subsequent alteration to the rules was initiated by Patrick, who intentionally tried to inject a loophole, but failed to specify the need to keep the files in order. His rules; he should have to live by them.

Also, I suspect that if Patrick had mentioned the need to leave the file names unaltered or in order, there's a good chance that Mike would have smelled a rat. After all, it is precisely in that side-channel where the information gain is to be had.

[DougBTX]

The "compressed" files includes a header file which records the original file name and the number of parts which make up the compressed file, so it doesn't depend on directory listing to re-combine the parts.

[emn13]

Yes, it does. It records the original file name, not the name of the parts, and it needs the names+metadata of those parts (specifically in this case their order) to reconstruct the original file.

[DougBTX]

Here's the script:

    #!/bin/sh
    i=0
    f=`head -1 $1`
    n=`tail -1 $1`
    rm -f $f
    while [ $i != $n ]; do
        cat $1.$i >> $f
        i=`expr $i + 1`
        if [ $i != $n ]; then printf "5" >> $f; fi
    done

The iteration is done with a while loop based on metatdata from the "compressed" file (the number of parts, $n) and the name of the archive ($1). The order of the parts is determined by incrementing $i up to $n, not from eg, the order of the files in the file system, which seems to be what was implied in the comment earlier.