Rob van der Heij wrote:
> no problems. Since the packed file is F1024 it will be padded with
> extra X'00' almost 99.9% of the time.
Only about 80%, I would hope? The least denominator of 1024/80 is 5, so
around 1/5 of the time (assuming some flattish distribution of sizes out
past 5kB) it should come out even.
The problem really is with the use of UNPACK. By design, following the
end of each packed file it looks for the start of another "sub-file",
and if that sub-file's not packed it's passed without error, just as if
the first file weren't packed. You can stick all the junk you want
inside the trailing part of the packed file without harm, but any junk
that spills over becomes the start of a new sub-file. Try this:
PIPE literal packed | pack | specs 1-* 1 "junk here" 100
| append literal not packed | cons | unpack | cons
For the problem at hand, the obvious workaround is just to verify that
the record is long enough to be part of the packed file:
PIPE < fn ft1 fm | fblock 1024 | locate 1024 | unpack | > fn ft2 fm
A more general workaround would be complicated, since UNPACK doesn't
give any indication that it reached EOF on the packed file. You could
watch for a record exactly matching the last record on the input, but
even that would fail in the rare case of a 1024-byte record with no
repeated characters that happened to start exactly on a record boundary.
¬R
