On Mon, 18 Sep 2006, David Berry wrote:
> I strongly suspect the 20-MAY-2004 change made to rec1_unpack_hcb.c by
> BKM. The history comment is "Do not attempt to unpack HCB for invalid HDS
> files". The change causes an error status to be returned if the file is
> not a valid HDS file, whereas before a success status was returned
> (presumably with garbage HCB values). Without this change, the call to
> rec_locate_hcb within rec_attach_file would return a good error status for
> an invalid HDS file, thus causing the following checks on hcb->stamp and
> hcb->version to be run. These would have detected that the file was not
> an HDS file, reported an error, and called rec_close_file.
>
> However, with the BKM change to rec1_unpack_hcb.c, the call to
> rec_locate_hcb within rec_attach_file will return a bad error status,
> causing the checks on hcb->stamp and hcb->version to be skipped, resulting
> in the file not being closed.
Yes after peering at all that, that looks about right to me too. The other
rec1_locate_hcb calls look like they could never generate this bad status,
so hopefully they are OK.
> I think my solution of adding an extra call to rec_close_file into
> rec_attach_file is reasonable, since the intention of RFWS was obviously
> that the file should be closed if no HCB info is available (as evidenced
> by the presence of the other two rec_close_file calls).
Yes, that must be right.
Cheers,
Peter.
|