File descriptor leak when hash/log files are corrupt or not matching

[seizethedave]

In our case we had hash/log files that were not corrupt but had different file_identifier fields due to problems in a writing pipeline. The result is sparkey_hash_open() will (correctly) return -305 (SPARKEY_FILE_IDENTIFIER_MISMATCH), but the log resources will not be cleaned up, because:

• in sparkey_hash_open, reader->open_status is not set when there's a file identifier mismatch (ditto any of the checks sparkey_hash_open does)
• sparkey_hash_close does nothing if reader->open_status is not set

The fallout is munmap and close are not called on the log file, leading to leaking file descriptors and the OS refusing to remove those bytes from the filesystem until the process is killed.

I intend to fix this problem, but figured I'd document it first!

[spkrka]

Thanks for the report! Since you intend to fix it, I will wait for the PR to review.