Files can be corrupted by rare spontaneous bit flipping, by mis-writing a block that was intended for another file or corrupting the block list to include data from another file (cross-linked files), by including blocks that don't exist, or by including blocks that have no data or arbitrary data.
Headers or meta data in some file formats can be verified by applications that support that file format, but it's possible for some of those problems to change the file's data such that the data is still valid, but wrong. If you have a large collection of media files or image files, filesystem corruption could potentially cross-link valid data from another file of the same type.
All of that is to say that the only way you can reliably detect corrupt files is to compare them to files that are known good. To anyone with backups in your position, I would simply say that the best option would be to wipe the system and restore a backup that you trust. If you had rsnapshot backups, you might be able to:
rsync -avcn /backup/ /filesystem/
rsync would then tell you which files differed from backup.
According to comment 39919031, Paragon HFS may have serious bugs. It's possible that the problem didn't actually come from the power loss, but from a bad filesystem driver. I'd recommend using something better supported by all systems for your shared space, or using hardware assited virtualization for all but one of the operating systems. On my own hardware, I run Linux with other systems in KVM guests, which works well. The host OS can export shared space over the network (NFS or CIFS) to the guests, which is probably the most stable filesystem configuration possible.