The answer above is wrong - if one bit on the disk changes, the ECC on the disk will correct it, or the e.g. a application image will become unusuable - cause a "segmentation violation". Change a bit in the node that refers to a file - and the file may be useless.
Do not muck around when you answer "bmick". You obviously do not know enough about hardware and operating systems. In better servers, even the RAM will use ECC to avoid single bit errors.
I see this consistently in the Java VM framework. And the bug is probably what you describe: That a new version of Java VM has changed SUID, the Disk Utilty use a wrong repository for what file permission is supposed to be.
Now Apple, the "Disk Utility" is GNU Open source. Update your repositories when new 3rd party OS components are installed. This makes the software run with apparent hang-ups. The modifications blocks access to files and makes the applications hang and even loose files and make databases corrupt.
To help you, Thunderbird works fine on Linux/Ubuntu, and I can even access the MacOS files from the Ubuntu partition. On MacOS I loose files - and get "Permission Inconsistency". You can look at the Linux list of bugs with HFS+, where they describe this error - that file permission is changed, where this is blamed on the journal update of files that remain open when the system is taken down - "Synced()".
Now, HFS+ on Linux will close the files, and flush the journal. MacOS' journal is not flushed on time, and updated later, and when a "Force Quit" is done you risk an error. Then you update with the wrong answer you introduce errors and for others to replicate these errors are very difficult, because they have exercised extensive effort to find out what they do wrong.
We will not use Ubuntu to correct MacOS, it is so much easier to use Ubuntu without the bugs.