You may want to come up with real examples of what is changing and what differs.
–
Martín MarconciniMay 8 '11 at 17:38

2

The cause of changes to file permissions is executing programs that perform these changes. I'm serious here: It's just too many possible causes if you don't narrow them down.
–
Daniel BeckMay 8 '11 at 19:41

2 Answers
2

First of all - random errors creep into any system. Modern hard drives have billions of bits stored and when you ask for a file to be written as 0101011 sometimes the machine writes 0101001 and if it's writing the permissions bits, there's your answer. If you do the math, assuming 99.99% accuracy would mean more than one error is on everyone's hard drive most of the time.

Things get cut off in the middle of finishing. Electrical noise crops up and messes up the signal, cosmic rays hit your memory chip and flip a bit, some program code isn't perfect so the math gets done wrong.

Then you have all the times another program wants to change the permissions and there is disagreement. Permission errors are usually logged to the system log so when you have a problem, have a look, maybe run permission repair to fix up the programs installed by apple.

Thanks for a succinct answer. The majority of the permission errors I have observed in my Mac occur with Java (1.6.0 jdk), and the JavaVM.Framework. They occur repeatedly.
–
SingularityMay 11 '11 at 17:02

Something like that sounds programatic or software since random errors should be distributed randomly. FSeventer or fs_usage might be worth deploying to see who is accessing those files. Highly concerning to have developer code self destructing like that. I might add them to a spotlight and time machine exclusion list temporarily to see if it's a collision of worlds between fseventsd / mds and java file IO. Curious if your filesystem is HFS+ journaled case-insensitive. I've seen other fs choices go wonky from time to time.
–
bmike♦May 11 '11 at 21:27

@neoneye, @bmike : Used FSEventer. The permissions change occurs in the same aforementioned directory, and each time Disk Utility "repairs" it, the permissions revert to their previous state, and this seems to be stuck in an endless loop. Possibly a conflicting configuration change by an application, or recurring false alarms by Disk Utility? I don't see any changes occurring prior to running Disk Utility though.
–
SingularityMay 12 '11 at 5:34

Wow. Keep in mind that Disk Utility just reads the receipts database that say how Apple wanted the files to be installed. If another program modifies them, Disk Utility doesn't agree with the changes so it's a game of cat and mouse. We know the cat is Disk Utility - fs_usage might let you know which program is the mouse.
–
bmike♦May 12 '11 at 15:54

Disk utility repairs the permissions, yet on a subsequent re-run of Disk Utility, the same permissions which got repaired are repaired again. I kept fs_usage running, there was no application/process which attempted an access to said directories/files. Could it be that Disk utility's attempted repairs on these folders/files aren't working at all?
–
SingularityMay 13 '11 at 12:22

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.

Thanks for chiming in with the Java VM expertise. Reading the comments after the question was posed, it sure looks like this was a case of "some program code isn't perfect so the math gets done wrong"
–
bmike♦May 27 '11 at 20:45