Another new switcher question: "Permissions Repair"?!?
Ever since getting my iBook and looking through forums I constantly read people talking about repairing permissions as a way to troubleshoot problems, a step taken when installing updates, etc... I never understood what this all meant.
So I tried doing a repair permissions of my own, with a fully working system, only to find it repair about 20 incorrectly "permitted" files. What the hell? I have installed maybe five new applications since getting my iBook, have installed all the updates, have never had a kernel panic and I always shut down properly.
My questions are these: How and why in the world do permissions in Mac OS X break so easily or need repair so frequently when nothing has been deliberately or explicitely damaged? If permissions break so easily, why is it that a typical Mac user who's not too familiar with computers would never learn about repairing permissions on his own, nor does Apple talk about this utility in the manual or state that it must be used when seemingly nothing is wrong (it is provided almost as a power-user tool). And, finally, why is it that this utility is even needed? Why does the OS exhibit this behaviour? Windows doesn't "mishandle" permissions, does it? I have never even heard of this problem before using OS X.
Someone please enlighten me on this issue... and hopefully it will not negatively affect my opinion of X if someone can educate me on this.
So I tried doing a repair permissions of my own, with a fully working system, only to find it repair about 20 incorrectly "permitted" files. What the hell? I have installed maybe five new applications since getting my iBook, have installed all the updates, have never had a kernel panic and I always shut down properly.
My questions are these: How and why in the world do permissions in Mac OS X break so easily or need repair so frequently when nothing has been deliberately or explicitely damaged? If permissions break so easily, why is it that a typical Mac user who's not too familiar with computers would never learn about repairing permissions on his own, nor does Apple talk about this utility in the manual or state that it must be used when seemingly nothing is wrong (it is provided almost as a power-user tool). And, finally, why is it that this utility is even needed? Why does the OS exhibit this behaviour? Windows doesn't "mishandle" permissions, does it? I have never even heard of this problem before using OS X.
Someone please enlighten me on this issue... and hopefully it will not negatively affect my opinion of X if someone can educate me on this.
Comments
the reason why they break is because many applications when installed are not set correctly in terms of permissions and they need to be reset...
its not a big deal, but it can fix the odd problem...
http://forums.appleinsider.com/showt...threadid=22781
has some good info on the subject
http://forums.appleinsider.com/showt...threadid=24880 has a good piece of software to get ahold of other useful, 'hidden' maintenance tools...
It's usually only necessary if/when you are having trouble installing a program.
I've seen Palm Installers and Shockwave installers need permissions repaired, but it had to be done manually.
Try other troubleshooting steps before running repair permissions, IMO. I sort of think of it as a doctor recommending to "take two aspirins and call me in the morning". Doesn't do much, but at least you took a pill.
http://docs.info.apple.com/article.html?artnum=106712
In general, three kinds of permissions can be assigned per the above associations: readability, writability, executability
In addition, there are special permissions that allow binaries to be executed as the specific user or specific group. And there are permissions that allow directories to let anybody manipulate their own files within them, but not other users' files... /tmp directories and drop boxes often function like this...
In the OS X GUI the only permissions you can change are readability and writability.
This isn't heard of much in the Windows world because even the NT based Windows operating systems have poorly integrated multi-user permissions.
Originally posted by Eugene
This isn't heard of much in the Windows world because even the NT based Windows operating systems have poorly integrated multi-user permissions.
Actually, ACLs as implemented in NT/2k/XP are way more flexible than the usual POSIX-style user/group/other rwx permissions. What exactly makes them "poorly integrated" in your opinion?
Originally posted by Eugene
All files have three sets of users associated with them: the individual owners of the file, the group owners of the file, and others.
In general, three kinds of permissions can be assigned per the above associations: readability, writability, executability
In addition, there are special permissions that allow binaries to be executed as the specific user or specific group. And there are permissions that allow directories to let anybody manipulate their own files within them, but not other users' files... /tmp directories and drop boxes often function like this...
In the OS X GUI the only permissions you can change are readability and writability.
This isn't heard of much in the Windows world because even the NT based Windows operating systems have poorly integrated multi-user permissions.
Thanks you all for this sort of information. However, I know all about this. I've been using Solaris/Linux for 3 years now. However, I've never needed to repair permissions on those two before. Solaris is a given because obviously admins would be in charge of that sort of thing. But do people have to repair permissions with Linux?
Also, Windows NT/2k/XP/2k3 do contain a multi-level rights system, which is different but surprisingly more complex than that of UNIX. I've been using NT kernel based Windows derivatives for years and have never heard of needing to repair permissions.
So this is more of what my question was asking. If this is a MacOS X exclusive issue, and why it is that it happens even beyond the user's control, such as in my case when I was following all of the correct procedures.
P.S. FYI: Most of the files that were found to be incorrect were files from Stuffit Standard 7.0.3, which I had installed after a fresh install of the OS. Could it be that this is a case of the Stuffit installer simply giving the files wrong permissions in the first place? I.e., this being a 3rd party application error and should not be blamed on OS X?
What happens when the Windows machine that stores the iTunes library isn't available (because it's restarting / off / not connected / ...)? In my experience, multiple things can happen. The one annoying thing is that iTunes hangs. Even more annoying is that sometimes, the whole GUI of EVERY application hangs, for >10 minutes. However, iTunes also sometimes just creates a _folder_ called "ITUNES" _locally_, meaning it's a folder "/Volumes/iTunes", which iTunes regards as the volume "ITUNES:".
Confused yet? In the case of permissions, it's often old-style installation programs that don't make sure that they have sufficient permissions to copy files over, or sometimes, they set up permissions wrongly (too permissive, or not permissive enough). Disk Utility keeps a list of various permissions as they're supposed to be, checks if they are like that, and changes them if necessary.
Originally posted by RazzFazz
Actually, ACLs as implemented in NT/2k/XP are way more flexible than the usual POSIX-style user/group/other rwx permissions. What exactly makes them "poorly integrated" in your opinion?
Flexibility doesn't mean squat when it becomes a "Pro" feature. It is not an option for XP Home, for example. In XP Pro, you have to dig through Folder Options to turn off Simple File Sharing first.
It's just another example of Microsoft hiding absolutely everything from the user.
Originally posted by ahbo
So this is more of what my question was asking. If this is a MacOS X exclusive issue, and why it is that it happens even beyond the user's control, such as in my case when I was following all of the correct procedures.
It's not really a Mac OS X specific issue. Repairing permissions in OS X is just a bit of housecleaning for when privileged users or apps run as privileged users accidentally change a files permissions. Installer.app has a tendency to do this sometimes.
Originally posted by Eugene
Flexibility doesn't mean squat when it becomes a "Pro" feature. It is not an option for XP Home, for example. In XP Pro, you have to dig through Folder Options to turn off Simple File Sharing first.
It's just another example of Microsoft hiding absolutely everything from the user.
I haven't really used XP home, but given its target market, I wouldn't think it's that big a deal. Does it not support ACLs at all, or does it just format your disk as FAT32 by default?
For XP Pro, yeah, having to unhide it first is a little annoying, but not that big a deal if you know what you're doing. Plus even with "Simple FIle Sharing" activated, permissions are enforced, and are set to restrict access to your personal files to yourself (unless you tell it to share them). Thanks to things like permission inheritance, this actually works quite OK, and if you want to, you can always enable full control. For NT and 2k you always get the whole deal.
Originally posted by RazzFazz
I haven't really used XP home, but given its target market, I wouldn't think it's that big a deal. Does it not support ACLs at all, or does it just format your disk as FAT32 by default?
It's crippled to FAT32 only.
I find the sharing and privelages system with NTFS to be quite flexible but also fairly cumbersome to use within the 2k/XP environment.
Anyway, thanks all for the explanations. I see now that a lot of the problems might be due to OS X having to support legacy applications as well.
But, I still feel that this is something that should be hidden from the user and fixed automatically when needed. For example, if it is recommended that this be done after system updates, then OS X should automatically invoke it after an OS update.
The same can also be said of fsck. I liked how in Win9x, if the computer was not shut down properly (power failure, etc), you were given the option of running scandisk at startup. This was removed in NT variations, but I feel it's a good feature to have, especially for the average user. It would be a lot more user friendly for OS X to bring up a prompt during boot time telling you that the volume was not unmounted correctly and may contain filesystem errors and ask to run fsck for you as many times as required, rather than expect the average user to learn how to interrupt the boot process and mess around with the console.
Originally posted by ahbo
But, I still feel that this is something that should be hidden from the user and fixed automatically when needed. For example, if it is recommended that this be done after system updates, then OS X should automatically invoke it after an OS update.
Agreed.
The same can also be said of fsck. I liked how in Win9x, if the computer was not shut down properly (power failure, etc), you were given the option of running scandisk at startup. This was removed in NT variations, but I feel it's a good feature to have, especially for the average user. It would be a lot more user friendly for OS X to bring up a prompt during boot time telling you that the volume was not unmounted correctly and may contain filesystem errors and ask to run fsck for you as many times as required, rather than expect the average user to learn how to interrupt the boot process and mess around with the console.
Actually, as far as I understand it, OS X does invoke fsck on every bootup, and checks if any file system was not unmounted cleanly, and in that case does a full check. It just doesn't tell the user about it.
Originally posted by RazzFazz
Actually, as far as I understand it, OS X does invoke fsck on every bootup, and checks if any file system was not unmounted cleanly, and in that case does a full check. It just doesn't tell the user about it.
Really? Can anyone verify this to be correct?
This is why I strongly encourage all users to enable journaling.
From a post I recently made in this thread:
Journaling is a feature that was added in 10.2.2 that can drastically help some systems. In short, it safeguards the filesystem so that it can practically *never* become corrupted. Whenever apps bug out or crash or the machine freezes, it usually has files open or is in the middle of writing to the disk. During those events, the fiesystem can get corrupted as the system writes bad data or forgets to close off files. Journaling keeps a record of all filesystem changes so it can instantly repair the disk without needing to scan through a lengthy disk integrity checker. Unfortunately, Apple only has a GUI toggle for this in the Server version of Mac OS X. Fortunately, it's easy to enable through the Terminal on any other regular Mac OS X installation or through the free utility Cocktail.
Before enabling journaling, though, it is imperative that you boot from the Mac OS X Install CD and run Disk Utility to repair any possible existing damage first because once you enable the journaling, it will preserve the damage that is already there. I can provide any additional details on the process if you like.
Originally posted by Brad
Yes, it does. However, it only runs fsck once. Sometimes if there is a little more extensive damage, fsck needs to be run several times.
This is why I strongly encourage all users to enable journaling.
Does enabling journaling cause any significant impact on system performance? Because it causes all disk transactions to be logged...
Estimates are a 10% slowdown on disk access times. Overall, whoop-dee-doo. The added security is *well* worth it.
Again, an old quote from something I did last year:
I repeated the entire procedure twice with journaling off and twice with journaling on, deleting the duplicate files and emptying the trash between steps. With each test, I was very careful to exactly dupilcate the procedure. I restarted twice between enabling journaling and timing the tests for the journaled setup. Unless otherwise noted, the files and programs are located on a 60 GB 7200 RPM IDE drive. Journaling was enabled on both my IDE and SCSI drives. I used a stopwatch to two decimal places but rounded the last digit.
cold startup:
regular 55 sec
journal 54 sec
launch c4d w/ bodypaint, pyrocluster, dynamics:
regular 14.9 sec
journal 14.9 sec
launch photoshop 7:
regular 18.8 sec
journal 18.9 sec
open 30 MB psd file (drag to psd icon in dock):
regular 18.5 sec
journal 18.5 sec
save 30 MB psd file to desktop from photoshop:
regular 9.1 sec
journal 9.5 sec
finder copy 790 MB file from 36 GB U160 SCSI 10000 RPM drive to the IDE drive:
regular 39.9 sec
journal 42.8 sec
finder open folder of 760 items in list view (on IDE drive):
regular 3.9 sec
journal 2.2 sec
finder duplicate said folder (65 MB, on IDE drive):
regular 28.3 sec
journal 32.0 sec
finder duplicate 1.05 GB file (on SCSI drive):
regular 1 min 26.4 sec
journal 1 min 26.5 sec
start Classic:
regular 16.8 sec
journal 15.7 sec
launch Final Cut Pro w/ camera connected:
regular 11.9 sec
journal 11.2 sec
average frame rate of 640x480 Snapz video capture with 15 FPS target:
regular 8.8 FPS
journal 10.0 FPS
Only file copy operations seemed to take any longer.
Originally posted by Brad
Actually, I'd say even less than 10% for a number of operations. I did my own sort of benchmarking when journaling was first introduced and found it almost always had a negligible effect on speed.
Thanks for the info!
Yes, I believe I read that journaling (on any type of FS) only affects performance on write operations, not read. That explains the lack of slowdown on your 'open' tests.
Just as it is prudent to try a simple reboot before reinstalling an entire OS, 'repairing permissions' is more appealing than other trouble-shooting routes. It has no down-side, and _might_ help, so it is frequently suggested. OS X really doesn't need to have its permisisons repaired that often. (IMHO of course)
Originally posted by Chucker
SMB share mounted from a computer upstairs,
What happens when the Windows machine that stores the iTunes library isn't available (because it's restarting / off / not connected / ...)? In my experience, multiple things can happen. The one annoying thing is that iTunes hangs. Even more annoying is that sometimes, the whole GUI of EVERY application hangs, for >10 minutes. However, iTunes also sometimes just creates a _folder_ called "ITUNES" _locally_, meaning it's a folder "/Volumes/iTunes", which iTunes regards as the volume "ITUNES:".
"freeze" upon SMB drop has its own technote
not the same issue.
as for some of the repairs detected,
Apple says a few are correct, just erroneously reported. nothing to see here.
local.nidb example
utmp example
as to why Microsoft doesn't report permissions violations as openly, um...
they're sometimes called Viruses, Worms, etc.
Patches are often permissions fixes in disguise.