The hash that is generated from the password is actually the derived key, and is definitely not stored inside the file (there are exceptions). It is not compared to any data, it is used for encryption and decryption.
There does not have to be something in addition to the ciphertext for the software to determine the password is correct. In many cases, decryption follows authentication, but it is not necessary to determine anything. The file will be decrypted, and decompression will most likely fail in the case of an incorrect password, if it does decompress the data will be junk.
That is of course not optimal from a usability standpoint. It is best for the user if they know the password is incorrect. That has to be done in a manner that does not give a huge advantage to an attacker. There are a several easy methods to accomplish this, here are a few of them.
1: A checksum or hash of the compressed data is added prior to encryption. Upon decryption, the data is then hashed, and compared against the decrypted hash. If it matches, it decrypted properly. This can also be done at a block level, such as every 16KB, so the correctness of the decryption can be determined earlier.
2: A "magic string" is the more common method in older encrypted archive formats. The compressed data includes some known prefix or suffix such as
0x52 0x61 0x72 0x21 0x1A 0x07 0x00 and
0xC4 0x3D 0x7B 0x00 0x40 0x07 0x00 in the case of WinRAR, and since the position of these strings should be in an expected location, decryption of those locations will reveal the string if the password is correct and the data is unmodified. This is not necessarily the way WINRAR handles it, but is just an example.
3: A secondary data encryption key is encrypted with a key derived from the password. This allows the password to be changed without reencryption of the data, and will also allow authentication of the data key component to know the password is correct, without having to look at the encrypted data of the archive.