Recently I have been having troubles with my multi touch motions on my UB macbook pro. I did a disk scan and found this. When I repair and restart it goes away but then comes back after a day or so. What does this mean?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What is this?
- Thread starter BigJohno
- Start date
- Sort by reaction score
"Will not be repaired" means: will not be repaired.
Arrgh, this is a really messy subject (which i think Apple needs to clean up) because there's a glitch somewhere in the / software update / installer.app / disk utility repair permissions / 3-pronged relationship.
Bottom line: DU is referencing outdated info when scanning some files, so it only thinks there's a problem (and "most likely" that /usr/share/derby item is perfectly fine, as is the suid item).
Too bad you posted a pic instead of copy/pasting from the log... because we can't see the full pathnames, and the blooper there appears to be twofold: on one hand it's talking about a changed suid file... and on the other it shows a link where it expected a folder. [edit: apparently "derby" is a symlink to a folder... and we can't see whatever the suid file is]
Like i said, that DURP report is probably false due to the aforementioned glitch.
If there's any "good" news here, that mess probably has nothing to do with whatever problem you're experiencing.
EDIT: it really burns me that such false reports exist... because — even now — we can't be 100% sure. Maybe that symlink is broken because its target folder is missing. We'd need to dig down there with Terminal to know for sure... since anything DU reports (permissions-wise) simply can't be trusted.
Arrgh, this is a really messy subject (which i think Apple needs to clean up) because there's a glitch somewhere in the / software update / installer.app / disk utility repair permissions / 3-pronged relationship.
Bottom line: DU is referencing outdated info when scanning some files, so it only thinks there's a problem (and "most likely" that /usr/share/derby item is perfectly fine, as is the suid item).
Too bad you posted a pic instead of copy/pasting from the log... because we can't see the full pathnames, and the blooper there appears to be twofold: on one hand it's talking about a changed suid file... and on the other it shows a link where it expected a folder. [edit: apparently "derby" is a symlink to a folder... and we can't see whatever the suid file is]
Like i said, that DURP report is probably false due to the aforementioned glitch.
If there's any "good" news here, that mess probably has nothing to do with whatever problem you're experiencing.
EDIT: it really burns me that such false reports exist... because — even now — we can't be 100% sure. Maybe that symlink is broken because its target folder is missing. We'd need to dig down there with Terminal to know for sure... since anything DU reports (permissions-wise) simply can't be trusted.
"Will not be repaired" means: will not be repaired.
Arrgh, this is a really messy subject (which i think Apple needs to clean up) because there's a glitch somewhere in the / software update / installer.app / disk utility repair permissions / 3-pronged relationship.
Bottom line: DU is referencing outdated info when scanning some files, so it only thinks there's a problem (and "most likely" that /usr/share/derby item is perfectly fine, as is the suid item).
Too bad you posted a pic instead of copy/pasting from the log... because we can't see the full pathnames, and the blooper there appears to be twofold: on one hand it's talking about a changed suid file... and on the other it shows a link where it expected a folder. [edit: apparently "derby" is a symlink to a folder... and we can't see whatever the suid file is]
Like i said, that DURP report is probably false due to the aforementioned glitch.
If there's any "good" news here, that mess probably has nothing to do with whatever problem you're experiencing.
EDIT: it really burns me that such false reports exist... because even now we can't be 100% sure. Maybe that symlink is broken because its target folder is missing. We'd need to dig down there with Terminal to know for sure... since anything DU reports (permissions-wise) simply can't be trusted.
Interesting. So this sounds like a common problem? What I still can't quite figure out is what is causing my trackpad gestures to not work if the error i got isn't connected.
The false disk utility reports are common, unfortunately.
I have no idea what's up with your trackpad. (Perhaps doing a restart clears out some accumulated crud somehwere, idunno. Sometimes things don't work as well after waking from a deep sleep. But even if you run DURP ten times in a row you'll still get those same lines every time, with or w/o a restart).
When I first installed Snow Leopard, I, too, got the "SUID" error when repairing permissions.
Seems to me I did some brief investigation into it, and the word was that it's a "phony error" - that is to say, of no real consequence and that it can be disregarded.
That was with 10.6
Since updatings to 10.6.2, not getting the error any more.
My advice:
I doubt that the error has ANYthing to do with "multi touch motions", or anything else of real consequence. I wouldn't be overly concerned about it. The LAST thing you want to do is major surgery (i.e., System re-install) for a miniscule problem like this.
Seems to me I did some brief investigation into it, and the word was that it's a "phony error" - that is to say, of no real consequence and that it can be disregarded.
That was with 10.6
Since updatings to 10.6.2, not getting the error any more.
My advice:
I doubt that the error has ANYthing to do with "multi touch motions", or anything else of real consequence. I wouldn't be overly concerned about it. The LAST thing you want to do is major surgery (i.e., System re-install) for a miniscule problem like this.