OS X Leopard 10.5.3 Upgrade Breaks iCal

Just a quick note on how upgrading to yesterday’s 10.5.3 release broke iCal, what didn’t fix it, and what did.

I upgraded yesterday, and everything seemed fine. It wasn’t until this morning that I tried to access my iCal, and I received an error dialog letting me know that iCal could not move the Calendar Cache due to a permissions problem.

I manually checked permissions on ~/Library/Calendars/Calendar\ Cache and the file was owned and writable by me, as well as the containing directory.

smeg:~ merlin$ cd ~/Library/Calendars
smeg:Calendars merlin$ ls -al Calendar\ Cache*
-rwxr–r–+ 1 merlin staff 532480 May 28 17:39 Calendar Cache
-rwxr–r–+ 1 merlin staff 311296 Feb 11 15:33 Calendar Cache~1

Running Permissions Repair inside of DIsk Utility did not help.

Moving the old Calendar Cache files out of the way did fix the problem, and the new iCal was able to upgrade and rebuld its databases:

smeg:~ merlin$ cd ~/Library/Calendars
smeg:Calendars merlin$ mv Calendar\ Cache Calendar\ Cache.bak
smeg:Calendars merlin$ mv Calendar\ Cache~1 Calendar\ Cache~1.bak

If you found this page because you have hit this problem, then I hope this helps.

-Chris

[ad#adsense-horizontal]

5 Replies to “OS X Leopard 10.5.3 Upgrade Breaks iCal”

  1. Oddly enough, once I had renamed my existing cache files, and let iCal do it’s upgrade, the resulting permissions were even more strict than before the upgrade, including group-read had been removed:

    smeg:Calendars merlin$ ls -al Calendar\ Cache
    -rw——-@ 1 merlin staff 528384 May 29 10:39 Calendar Cache

    -Chris

  2. Note the + in the “old” permissions, and the @ in the “new” permissions: there were ACLs on the files, and now there are extended attributes on the files. Use “ls -l@” to see the extended attributes and permissions on a file in Mac OS X.

  3. While you are correct, there was an ACL, it should not have interfered with my user account’s ability to edit/replace/delete the files in question. As a test, I created a file, gave it the same ACL, edited it, and then deleted it:

    smeg:Calendars merlin$ touch /tmp/test.txt
    smeg:Calendars merlin$ chmod +a “group:everyone deny delete” /tmp/test.txt
    smeg:Calendars merlin$ ls -al@e /tmp/test.txt
    -rw-r–r–+ 1 merlin wheel 0 Jun 4 13:53 /tmp/test.txt
    0: group:everyone deny delete
    smeg:Calendars merlin$ vi /tmp/test.txt
    smeg:Calendars merlin$ rm /tmp/test.txt
    smeg:Calendars merlin$ ls -al /tmp/test.txt
    ls: /tmp/test.txt: No such file or directory

    No access ussues along the way.

  4. Thank you SO much! I have been working on this problem for months and yours was the perfect solution. It was so frustrating and now you’ve made my day!
    Thanks!

Leave a Reply to ChrisKnight Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.