Incorrect SFileInfoNameHash1 & SFileInfoNameHash2 being returned about stormlib HOT 4 CLOSED

I think this is due to a bunch of fake & duplicated hash table values, making it hard to know which hash table records are real.

Some of the fake entries can be resolved using an external list files, and will successfully extract, but the binary data is garbage.
For example:
(PC)WorldEditMenu.html

I'm researching this more to see if I can fix it on my end with some Deep File Verification. Maybe not StormLib's job to handle this scenario.

from stormlib.

What you see is a fundamental problem of opening file by pseudo-name.

Unlike classic file open (FileName --> NameHash+HashTableIndex --> BlockIndex --> FileData), opening by pseudo-name goes directly into BlockIndex. Yes. The number in the name ("File00024483.blp" --> 24483) is the decimal block index. The extension is provided only when StormLib is able to determine it by file content, but it's generally ignored by SFileOpenFileEx.

Now we opened a file by block index, where to take that damn hash index?

When a file is opened by pseudo-name, StormLib tries to determine the hash index by searching which hash entry points to block table entry whose index is given in the pseudo name. This generally works well, except the case when MPQ has cross-linked files (multiple files names pointing to the same file data).

Cross-linked files may be legal (why couldn't multiple files have the same data, right?) or malformed (MPQ protectors slowing down MPQ opens).

Now I guess that the best (or "least-worst", if you want) way to fix it is to not return any hash entry when those two conditions are met:

1. A file is open by pseudo-name
2. Multiple hash table entries pointing to that block entry.

from stormlib.

Thanks for the explanation. I don't think this is a bug in StormLib, nor should StormLib handle it any better/differently, so I'm closing it.

I've been able to work around the issue by coding my own custom filename & hash verification methods. It's pretty complicated & WC3 specific. I'm basically regex scanning all extracted file contents for filenames & checking against SFileHasFile.

In my case if there are 2 hash entries pointing to 1 block I'd prefer to get ALL the possible hashes for a fileIndex, rather than 1st or none. But, there's no reason to make a breaking change to the StormLib API based on my specific use case & corrupted map. I can workaround the problem.

Thanks for the help!

from stormlib.

I made the fix described above in this PR: #316

Callers of SFileGetFileInfo(hFile, SFileInfoNameHash1, ...) must test the result of the call.

from stormlib.