Lost Wiki calendars after upgrade to 10.6.4

Andre, ct181,

finally it works! Note to myself: always erase the principals.pyc file before starting iCal back up! This was for one or the other reason my problem that the compiler did not recreate the .pyc file in the same directory and as such the fix of you, Andre, couldn't work.

Hack reapplied to original principals.py, iCal stopped, principals.pyc removed, iCal started, works!

Thanks for the help!

Regards

Andi

Hallo Andre,

Thank you for your fix and your help. We are now very happy that the "wiki" Calendar is back again 😉
Next week i have to drive around my customers because they all have updated to Mac OS X 10.6.4 and messed up their wiki calendars.

Now we can bring them back. Thank you. Thank you.

Nice weekend to everybody.


BTW: I have downloaded the new principal.py file so i do not have to work around with text editors and it works like a charm.

Andre, thank you. The Python change made it work for me as well. But I'm rather uncomfortable with this, as 10.6.5 or any other update could remove this, am I correct? And the code could change enough that this fix no longer would work if reapplied?

Thanks again for your work. We're not beating you up for this. Just the decisions made by Apple et al in regards to this.

I've implemented another successful workaround that doesn't involve hacking the Calendar Server code. Instead, I've utilized a different hack that might raise some eyebrows but gets the job done: hard-linked directories. (See http://stackoverflow.com/questions/1432540/creating-directory-hard-links-in-maco s-x for working code.)

On my home network I set up three wikis to allow my wife and I to share common information. The wiki calendar was compelling not for the ability to share---delegation would work just fine for that---but rather because it is sometimes convenient to manage items via the web interface rather than needing to fire up the iCal client.

Because of the way Apple implemented things, each of these three wikis required the creation of a dedicated group in Open Directory. For consistency, I also created dedicated accounts to own each group. However, this means that each wiki ended up with three distinct entities that are addressable by Calendar Server. But for my situation, there will never be a reason why the calendar data should differ among the three related entities. So I did the following for each wiki:

1. Use WGM to look up the Generated UID for the associated user and group
2. Create appropriate directories under /Library/CalendarServer/Documents/calendars/_uids_/ for these accounts (e.g. /Library/CalendarServer/Document/calendars/_uids_/01/23/01234567-89AB-CDEF-0123-456789ABCDEF )
3. Hard-link the path /Library/Calendar/Server/Document/calendars/_uids_/wi/ki/wiki-<wikiname>/calendar into each of the directories created in step (2)
4. Restart Calendar Server
5. Open up iCal client under an administrator account (well, not strictly necessary but perhaps cleaner than using your personal account)
6. Use Preferences->Accounts to add the group-owner account and then use Delegation to grant read/write access to appropriate users
7. The group's users may now use iCal client Preferences->Accounts to remove the accounts previously used to set up the wiki calendars and re-add them via the Delegation tab

This solution will not work well for some environments, particularly if there are security requirements to avoid 'application' accounts or to maintain separation between the wiki and WGM group access levels. Moreover, maintaining this solution could rapidly become tedious for groups with many members and/or frequent membership changes. Indeed, I'm only intending to maintain this setup until such time as Apple cleans up the way iCal client munges URLs and (maybe more importantly) consolidates the wiki/iCal/WGM metadata handling into something less fragmented. But for the moment it seems to get the job done.

I'm sure some Apple peeps will object on the basis that those of us outside the Mac OS dev teams (and the Time Machine devs in particular) shouldn't play with directory hard-linking, ever. But I'll take my chances: IMHO, it seems far more likely that 10.6.5 will contain patches to Calendar Server than it will remove directory hard-linking from HFS+.

Message was edited by: Ian Barton

Andre, Thanks!

The fix to the python files works great.

Duro: Technically, yes. However that fix has been applied to the Release tree in the repository, so one can hope that Apple will update iCal server to include the change with 10.6.5. Admittedly this is relying on luck since the server products tend not to be updated as often as the client products, but we can hope. If it is not updated, it is possible to see a reversion of this fix, however if that does happen reapplying the fix is trivial (with the exception of updating any workstations that were improperly updated to the wrong principals URL - but a little good planning to do the update when systems are not online helps mitigate that issue).

Andre,

thank you for your workaround, but where can I find the /usr/...../principal.py path? Sorry for my ignorance of these things!

thanks!

jochen

... sorry, no /usr/... path in my directory.

wow, now it finally works !

Thank you very much indeed!

One related issue we encountered after running the 10.6.4 update was that on about half our systems was the cached caldav data from the earlier version of iCal client was making the new version of iCal client crash on load. To fix this, we had to go into the user directories and delete the caldav caches:

~/Library/Calendars/*.caldav
~/Library/Calendars/Calendar Cache

(do not know which deletion actually fixed the issue)

Once deleted, the next run of iCal recreated the cached data and everything was good. Luckily this didn't affect local calendars for us, though I can see the potential for that...

Warning: Do not delete the *.calendar or *.group directories; those are your local calendars!

DurocShark wrote:
Andre, thank you. The Python change made it work for me as well. But I'm rather uncomfortable with this, as 10.6.5 or any other update could remove this, am I correct? And the code could change enough that this fix no longer would work if reapplied?

Thanks again for your work. We're not beating you up for this. Just the decisions made by Apple et al in regards to this.

Hello,

Your concerns are absolutely justified. Any time you modify an apple-supplied file, you run the risk of having those changes clobbered by a future update to that file.

In this specific case, the scope of the change is very small, and the 'reward' for the change is pretty large - for users who have come to rely on the wiki group calendar workflow.

As with any unsupported changes made to the OS, this should be added to a list of items to review and test when evaluating future system updates.

I would also echo the other comments from Random Chaos in response to your question, however keep in mind that no promise will be made regarding whether this fix will show up in a system update.

Thanks,
-dre

In my opinion this change isn't so bad... But Apple should offer us the option to add a "group account" or "wiki account" instead of just user accounts in iCal and iPhone.

This would solve ANY hack (eg, hacking the py file or changing the paths) and it would just work on the first go, without altering a user account on a per computer basis.

Apparently wiki calendars are a pretty often used feat... So Apple should work with that information and make it a proper feature, Apple style. idiot proof, separate entries NEXT to your regular user account and so on. It will be magical if they do.

I tried doing Andre's fix, followed all the steps, turned off iCal, deleted the .pyc file and then restarted iCal and the .pyc file is not regenerating for me. What is going on here?

When I restore the original principal.py, the principal.pyc file regenerates fine. I'm using textmate to edit the file so maybe there is a compilation error?

So frustrating... we have to hack this highly demanded feature.

** UPDATE: I fixed it. I forgot I'm dealing with python which is tab sensitive. TextMate was inserting tabs rather than spaces and it was confusing the compiler. Make sure you guys use spaces to indent your lines or have TextMate convert tabs to spaces.

Message was edited by: Michael Narciso

Andre's fix worked for me as well. Thank you very much!