I’d like to share my knowledge on this topic, since I’ve spent quite a long to time to find out how to do it.
The PropertiesFile class uses a file somewhere in /Library/Application Support or /Library/Preferences, which is protected against writing on Lion (and I think also Mountain Lion). This means a normal Application can only read the PropertiesFile but not write it. To be able to write to this folder, the Application has to be startet with root privilege.
It can be discussed, if it is good practice or not to write to /Library/Application Support but sometimes it can be necessary. A common way pointed out by an apple document is to split the part of the Application that does the root stuff into a seperate application and start it from the main Application. The binary file (Bundle/COntents/MacOS/…) must have to SUID Bit set, to ask for the root Password at startup.
This could be the solution, but the real ful began here: I already had a PropertiesFile in the target location and my application was not able to overwrite it with a new version, although the application was startet with root permission.
In the end I found, that the JUCE XML Class refuseses to write the file, because it checks the write permission by using File::hasWriteAccess(). This method itself uses the access() function to determine if it is allowed to write. Unfortunately access() only takes the real user ID into account and does not see that the user has root privilege due to the SUID BIt or a sudo command.
Now the question is: Is this a bug, or is this a feature. As far as I can see, a system wide PropertiesFile can not be written on Mac at all, unless root itself is logged in. (Is that possible on Mac? Anyway it is not desired.)
In my opinion the solution would be to change the File::hasWriteAccess() method in a way that is does not uses access() any more. Any other suggestions?