Do persistently incorrect disk permissions indicate a disk should be replaced?

Question

Something is wrong with my Mac, as indicated (and still unresolved) in the question: What is the Sixth Step of MacBook Repair?

One possibility is that the main disk is faulty.

Disk Utility reports that the disk permissions are corrected if I run "Repair Disk Permissions". I do this after "Verify Disk Permissions" says that:

Permissions differ
on "System/Library/CoreServices/RemoteManagement/.../UIAgent.nib;
should be -rw-r---r--; they are drw-r---r--.
Permissions differ
on "System/Library/CoreServices/RemoteManagement/.../MainMenu.nib
should be -rw-r---r--; they are drw-r---r--.

(8 similar set of errors are reported)

But then if I once again run "Verify Disk Permissions", the exact same set of permissions are reported.

Do I:

1. call the disk unreliable and replace it,
2. reformat the disk (and reinstall OSX) hoping the bad sectors would be flagged and avoided,
3. do something more nimble?

Exactly the same problem happens if I run Disk Utility from the OSX DVD.

Edit It's a bit annoying, but even after a partition/format/install OSX sequence, some permissions are incorrect out of the box.

Group differs on “Library/Java”; should be 0; group is 80.
Permissions differ on “Library/Java”; should be drwxr-xr-x ; they are drwxrwxr-x .
User differs on “usr/share/collabd/webauthd”; should be 94; user is 221.
Group differs on “usr/share/collabd/webauthd”; should be 94; group is 221.
User differs on “usr/share/collabd/webauthd/locales”; should be 94; user is 221.
Group differs on “usr/share/collabd/webauthd/locales”; should be 94; group is 221.
Permissions differ on “usr/share/devicemgr/frontend/admin/zh_TW.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/zh_CN.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/ru.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/ko.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/nl.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/it.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/es.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/fr.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/de.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Permissions differ on “usr/share/devicemgr/frontend/admin/ja.lproj/app/javascript.js”; should be lrwxrwxrwx ; they are lrwxr-xr-x .
Group differs on “Library/Preferences/com.apple.alf.plist”; should be 80; group is 0.

Answer 1

Usually, you'd ignore the problem. It just means that contradictory permissions are specified for those files. It can't satisfy all of them at once.

In Mac OS X v10.5 or earlier, when you verify or repair disk permissions Disk Utility reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature).

Source: About Disk Utility's Repair Disk Permissions feature

The problem here is that different receipts specify different permissions for a file. If it sets them one way, they're wrong according to the other.

I think Apple used to mention possible contradictions in permissions, I'll see if I can find it.

But in your specific case:

Looking at the specific permissions in your log, I doubt this applies to you. The d indicates a directory, which means a file has been replaced with a directory. Fixing permissions is not going to fix this; it can't transform the directory back to a file.

I suspect this would be fixed with a reinstall. I doubt the disk needs replacing, however.