Is PACK on the HP-71 buggy?

[Joe Horn]

IN BRIEF: Does the PACK command in the HP-71 screw up LIF disk images mounted in ILPer when using a PIL-Box?

BACKGROUND: When a file is deleted on a LIF disk, it leaves a "hole" in the directory and data area (the file type is merely changed to 0000, but the file's name and contents remain on the disk). The PACK command on the HP-71 eliminates those holes by packing the directory and the data area, by shifting everything after the holes upwards, filling up the holes. After PACK, all available space is in a single block at the end of the directory, and in a single block at the end of the data area.

DISTURBING OBSERVATION: Using the PACK command with an HP-71 (rev 1BBBB; physical one, not emulator) and a PIL-Box (rev 1.5) and ILPer (ver 1.43) does more than just pack the disk image; it also writes bogus information into the directory area, almost without fail, even when no packing is needed.

EXAMPLE: I have a LIF disk image called "DIVISORX Lex.dat" whose hex contents originally began like this:



As you can see, the disk only contains two files (DIVISORX and DIVISORS), followed by the directory area, five entries of which (highlighted in yellow above) happened to contain zeroes instead of the usual FF's, but that shouldn't matter. The disk's directory size is 616, of which 614 are available. No packing of the directory is needed, since it contains no deleted files.

After mounting that disk with ILPer, and executing PACK on the HP-71 via a PIL-Box, that LIF image file's hex contents changed to this:



As you can see, five bogus directory entries magically appeared, AFTER the "end of directory" line at hex position 0240. These five files are nowhere on this disk; in fact (strange to tell!) they were on the previous disk which I PACKed! Apparently PACK leaves some directory data in RAM somewhere, and that old data gets written to the next disk that gets PACKed!

After doing this many times, to many different LIF images, I have observed that it doesn't matter whether or not there are any zero'd directory entries; bogus ones get written in both cases. The good news is that they always seem to get written after the end-of-directory marker... but the bad news is that if the directory is full (or almost full), the bogus entries MIGHT obliterate the beginning of the data area, which scares the heck out of me.

Notes: The PACKDIR command exhibits this same behavior. The number of bogus directory entries written is not always 5.

QUESTIONS: Is this a known and harmless artifact of PACK and PACKDIR, or is it a bug? If it's a known bug, is there a reliable workaround?