Previous 1 2 Next 16 Replies Latest reply: Apr 30, 2008 11:22 PM by jetjoe
IanB Level 4 Level 4 (1,370 points)
I know this has been discussed a lot here but I'm having trouble finding the definitive solution. If someone can point me in the right direction I would be grateful.

I click Repair Permissions and it says Estimated time: Less than 1 minute.

Hours later it finishes.

This gives me no confidence that it is working.

How do I get it to run at about the same speed as it used to in Tiger - a minute or so?

Thanks

iMac 17" Flat Panel, Mac OS X (10.5.1)
  • Trinity Level 4 Level 4 (2,855 points)
    I'm repairing permissions in my Cube for the last 18 hours. And Disk Utility is not freezed, it just checks or repairs every file for about 50 times.
  • Thierry de Villeneuve Level 1 Level 1 (125 points)
    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.

    Rgds,
  • sklon Level 1 Level 1 (5 points)
    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
  • Thierry de Villeneuve Level 1 Level 1 (125 points)
    Thank you,

    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
    total 569624
    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
    Password:
    bash-3.2# /usr/bin/sqlite3 /Library/Receipts/db/a.receiptdb vacuum

    bash-3.2# ll /Library/Receipts/db/
    total 555240
    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))
    7364608
  • Barry Hemphill Level 8 Level 8 (36,685 points)
    Hello ian:

    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.

    Barry
  • IanB Level 4 Level 4 (1,370 points)
    Hi Thierry,

    I can see you are whacking a few unix commands into a bash shell there but can you explain what they do for me?

    Thanks

    Ian
  • Thierry de Villeneuve Level 1 Level 1 (125 points)
    IanB wrote:
    Hi Thierry,

    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.

    http://en.wikipedia.org/wiki/SQLite3

    I use the 'vacuum' command that cleans and reorganize the DB file. This has for effect to optimize read accesses to the database

    http://sqlite.org/lang_vacuum.html

    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.

    Thierry
  • IanB Level 4 Level 4 (1,370 points)
    Hello Barry,

    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.
  • IanB Level 4 Level 4 (1,370 points)
    Thanks Thierry,

    I shall give it a try to see if it speeds up my permissions repair and report back. I'm still interested to understand why Barry thinks that it is unnecessary and to get feedback from others on that.

    Best regards,

    Ian
  • Komkommer Level 1 Level 1 (30 points)
    I run Disk Permission one time every week and it runs for about a minute or two..
  • IanB Level 4 Level 4 (1,370 points)
    Hi Komkommer,

    Thank you for responding.

    Interesting. I wonder what the difference is between our systems then. Mine has already been running for about 10 minutes.
  • Barry Hemphill Level 8 Level 8 (36,685 points)
    Hi Ian:

    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.

    Barry
  • IanB Level 4 Level 4 (1,370 points)
    Hi Barry,

    I wasn't trying to cast any aspersions on your assertion, just trying to understand how formed the conclusion - sorry if I offended you.

    Thanks very much for taking the time to respond to my post.

    Best regards

    Ian
  • Barry Hemphill Level 8 Level 8 (36,685 points)
    Hello Ian:

    I sometimes tend to be abrupt - a hangover from my days in the business world. No offense taken!

    Barry
Previous 1 2 Next