I won't worry of that. I've tried Repair Permissions and "Sampled" the _installdb process.
I've a dual core MBP, and it went pretty "fast" compared to what has been posted here (few minutes or so).
As I do such Repair Permission quite frequently, I presume it's keeping the DB where the list of files and permissions are kept, in a clean and optimisez way.
My next personal assignment will be to identify where this DB file is located and do a "vacuum" on it. OsX is using sqlite to create storage DB files. "vacuum" is a sqlite command to clean up and update DB files indexes (if any).
For instance, you can try that on Mail.app
/usr/bin/sqlite3 ~/Library/Mail/Envelope\ Index vacuum
I'm pretty sure Disk Utility has such index file somewhere. The _installdb process has completed before I've had time to "lsof" it.
Perhaps someone can help us here with some more clues.
mb:~ sam$ sudo lsof | grep install
installdb 23336 _installer cwd DIR 14,2 102 27 /Library/Receipts/db
installdb 23336 _installer txt REG 14,2 185424 1815796 /System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/instal ldb
installdb 23336 _installer txt REG 14,2 1059536 21253 /usr/lib/dyld
installdb 23336 _installer txt REG 14,2 133345280 7951470 /private/var/db/dyld/dyldshared_cachei386
installdb 23336 _installer 0r CHR 3,2 0t0 109795588 /dev/null
installdb 23336 _installer 1 PIPE 0x694ba8c 16384
installdb 23336 _installer 2 PIPE 0x694ba8c 16384
installdb 23336 _installer 3u unix 0x6e8baa0 0t0 ->0x694add0
installdb 23336 _installer 4u REG 14,2 318615552 29 /Library/Receipts/db/a.receiptdb
installdb 23336 _installer 7u unix 0x6ead4c8 0t0 ->0x6ead110
That did it. It shrunk the DB file down 7364608 bytes ... and optimized index performance, for the most.
This is something people out here that experience very slow "repair permission" could do, preventively
bash-3.2$ ll /Library/Receipts/db
0 drwxr-xr-x 3 _installer admin 102 Feb 12 15:35 .
0 drwxrwxr-x 88 root admin 2992 Feb 12 08:29 ..
569624 -rw------- 1 _installer wheel 291647488 Feb 12 15:35 a.receiptdb
bash-3.2$ sudo -s
bash-3.2# /usr/bin/sqlite3 /Library/Receipts/db/a.receiptdb vacuum
bash-3.2# ll /Library/Receipts/db/
0 drwxr-xr-x 3 _installer admin 102 Feb 12 23:34 .
0 drwxrwxr-x 88 root admin 2992 Feb 12 08:29 ..
555240 -rw------- 1 _installer wheel 284282880 Feb 12 23:34 a.receiptdb
bash-3.2# echo $((291647488 - 284282880))
Lets try to get up out of the UNIX sandbox and address your question. Permission repair is, IMHO, very rarely needed. The days when it was equivalent to aspirin for the Mac are gone.
In any event, permission repair takes quite a bit longer under OS X 10.5 that it did under OS X 10.4. I read a very complete description of why this happens, but, candidly, I could really care less.
If Disk Utility completes and indicates permissions repair completed (without error messages) you are in good shape.
The last time I ran it the program took something under 30 minutes. The hang at one minute left for a long time is expected behavior at this point - again, I do not know why.
I can see you are whacking a few unix commands into a bash shell there but can you explain what they do for me?
Indeed! But I can't go to in detail on "how to" manage your Mac through a Unix shell. It's a bit of topic here. Anyways, here are some explanations on the commands themselves.
First I realize I've used one of my shell aliases 'll'. It's a command built in the Korn shell, that doesn't exists in Bash. So, I've created a convenient alias, that allows for some uniformity between the Unix shells I have to cope with.
alias ll='ls -alsG'
I've listed the content of the /Library/Receipts/db directory, which I'm allowed to read (and execute). This reports the presence of this file: a.receiptdb
That's it, it's what I'm looking for: the DataBase file MacOSX uses for many of its applications (thanks to a built-in SQL engine)
Apple provide a simple SQL client 'sqlite3' to manage and access these DB files. I prefer to provide the absolute path to this command to be sure I'll use the Apple provided binary and not some other 3rd party (or Darwin ports installed) version.
I use the 'vacuum' command that cleans and reorganize the DB file. This has for effect to optimize read accesses to the database
You can excercise this 'sqlite3 vacuum' command onto your Mail Envelope Index file too. This makes Mail.app a tad bit faster browsing through your mails.
Finally, I've listed again the directory content to see how much space that file has freed on my HD. It means that my DB file needed some clean-up/reorg.
That command 'echo $((291647488 - 284282880))' is simply to use the math functions of the Bash shell I've used here as a simple calculator.
The receipts DB file is appended with information about installed packages. It's used by Repair Permissions (of Disk Utility) and Software Update. Both applications need to read the patterns defined by the applications designers to correctly apply the Unix permissions to each of the files installed/created by applications ... MacOSX system in first place.
I hope this will help.
Thanks for responding.
You wrote: "Permission repair is, IMHO, very rarely needed."
That runs contrary to all the advice I've ever been given on these discussions pages. I routinely check permissions before and after any software installation as advised by many here and the X Lab stuff. I started doing this when I had a problem in Tiger and I've never suffered a similar issue since.
How have you formed the conclusion that permissions repairs are no longer important?
No matter if it's necessary or not, I'm not bothered if my permissions repair lasts 30 minutes but I am bothered if it lasts six hours like it did last time.
I qualified my observation by saying it was "+in my humble opinion."+ Actually, my opinion is not particularly humble as you can see by the little blue things that I have been posting and reading these forums for a very long time. People who are far more technical than I (L4 and L5 posters) seem to have come to the consensus that repairing permissions is most probably a waste of time. That is not true if one is troubleshooting and, in fact, I suggest that in numerous situations (among other things).
If you have time on your hands, search these forums and find a post that says that permission repair fixed anything (you will find few, if any).
Repairing permissions used to be a "standard" troubleshooting recommendation. That thought process still hangs around in some places. Certainly running permission repair (using Apple's disk utility) will not hurt anything. Frankly, I think that running repair disk (or DiskWarrior) occasionally would be a much better use of time.
To be honest, the old ways die hard. I do run permission repair after I perform software updates - although the messages have been, to date, irrelevant.