 |
 |
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.