Lost Wiki calendars after upgrade to 10.6.4

Hi,

This is a user to user forum.

You could notify Apple by making report on their feedback form for iCal (which they have overhauled recently, but still does not have iCal version 4 as an option!!).

You could also make a report to Apple by their Bug Reporter system. You need an ADC account, but they do offer a free one.

You could also join the CalDAV user's list and see if anyone there can give you some pointers. http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users

It might also be worth looking at http://trac.calendarserver.org, to see if they have anything on your problem.

Best wishes

John M

Hi,

I know it will not help you but you are not alone.
The same happens to me and I will now dive into the problem.
I will upgrade the server to 10.6.4 now and i hope that this will help.

I will come back later and post my results.
Mike

so.. we are completely not alone. another topic:
http://discussions.apple.com/thread.jspa?messageID=11685843

The threat name is different but it is the same issue.

so. i installed the server update and it is not working.
tried to copy the ical.app to the 10.6.4 computer and it is not working.

so... i dont know what to do know. it seems like a bug to me

A followup from my post here: http://discussions.apple.com/messageview.jspa?messageID=11686666&stqc=true


Looking at server debug error logs in Info mode, it appears that when querying for the group's HEX UID, the server does the following process:

- Creates a wiki record for the GUID in Memcache; the correct data appears to be passed from the wiki entry
- Checks state of GUID, fails to find it
- Removes memcache data
- Returns "Not Found" to the client

Anyone know why the Twisted is failing to successfully create the Memcache entry?


This is the log of the events dealing with the targetted UID:


2010-06-17 11:00:40-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Creating wiki record with GUID 4946e8b4-dbee-59aa-9064-37bc5ae59154
2010-06-17 11:01:01-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.cache.MemcacheResponseCache#debug] Adding to cache: '04a59fceaad709e7fcbbe8a1a846fa43' = '((I0\nNtp1\nI5849565769670424107\n(I0\nNtp2\n(I207\n(dp3\nS\'Last-Modified\'\n p4\n(lp5\nS\'Thu, 17 Jun 2010 15:01:01 GMT\'\np6\nasS\'DAV\'\np7\n(lp8\nS\'1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search\'\np9\nasS\'Content-Type\'\np10\n(lp11 \nS\'text/xml\'\np12\nasS"<?xml version=\'1.0\' encoding=\'UTF-8\'?><multistatus xmlns=\'DAV:\'>\\r\\n <response>\\r\\n <href>/principals/wikis/acgiit/</href>\\r\\n <propstat>\\r\\n <prop>\\r\\n <principal-collection-set>\\r\\n <href>/principals/</href>\\r\\n </principal-collection-set>\\r\\n <calendar-home-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/ _uids_/wiki-acgiit</href>\\r\\n </calendar-home-set>\\r\\n <calendar-user-address-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>urn:uuid:4946e8b4-dbee-59aa-9064-37bc5ae59154</href>\\r\\n <href xmlns=\'DAV:\'> https://server.redacted.tld:8443/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'> https://server.redacted.tld:8443/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>/principals/ _uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'> http://server.redacted.tld:8008/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'> http://server.redacted.tld:8008/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </calendar-user-address-set>\\r\\n <schedule-inbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/ _uids_/wiki-acgiit/inbox/</href>\\r\\n </schedule-inbox-URL>\\r\\n <schedule-outbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/ _uids_/wiki-acgiit/outbox/</href>\\r\\n </schedule-outbox-URL>\\r\\n <dropbox-home-URL xmlns=\'http://calendarserver.org/ns/\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/ _uids_/wiki-acgiit/dropbox/</href>\\r\\n </dropbox-home-URL>\\r\\n <displayname>acgiit</displayname>\\r\\n <principal-URL>\\r\\n <href>/principals/ _uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </principal-URL>\\r\\n <supported-report-set>\\r\\n <supported-report>\\r\\n <report>\\r\\n <acl-principal-prop-set/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-match/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-property-search/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <expand-property/>\\r\\n </report>\\r\\n </supported-report>\\r\\n </supported-report-set>\\r\\n </prop>\\r\\n <status>HTTP/1.1 200 OK</status>\\r\\n </propstat>\\r\\n <propstat>\\r\\n <prop>\\r\\n <xmpp-uri xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n <notification-URL xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n </prop>\\r\\n <status>HTTP/1.1 404 Not Found</status>\\r\\n </propstat>\\r\\n </response>\\r\\n</multistatus>"\np13\ntt.'
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: checking dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: miss dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Faulting record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] opendirectory.queryRecordsWithAttribute_list(<PyCObject object at 0x101b47670>,'dsAttrTypeStandard:GeneratedUID','4946e8b4-dbee-59aa-9064-37bc5ae 59154',8193,False,['dsRecTypeStandard:Users', 'dsRecTypeStandard:Groups', 'dsRecTypeStandard:Places', 'dsRecTypeStandard:Resources'],['dsAttrTypeStandard:GeneratedUID', 'dsAttrTypeStandard:RecordName', 'dsAttrTypeStandard:AltSecurityIdentities', 'dsAttrTypeStandard:RecordType', 'dsAttrTypeStandard:RealName', 'dsAttrTypeStandard:FirstName', 'dsAttrTypeStandard:LastName', 'dsAttrTypeStandard:EMailAddress', 'dsAttrTypeStandard:AppleMetaNodeLocation', 'dsAttrTypeStandard:GroupMembers', 'dsAttrTypeStandard:NestedGroups', 'dsAttrTypeStandard:ResourceInfo', 'dsAttrTypeStandard:ResourceInfo'])
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Failed to fault record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: storing (negative) dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.principal#error] No principal found for UID: 4946e8b4-dbee-59aa-9064-37bc5ae59154

I'm reporting the same problem here. Although I don't think it's a server issue. This morning one of the clients on my network updated to 10.6.4 and that immediately killed it's connection to the group calendar on iCal Server running on a mini with Snow Leopard Server 10.6.3.

I figured it could have been a problem with the client having a higher version than the server so I went on and run the update on the server too. I did not update my MacBook Pro or other mac client.
Indeed after server rebooted the 10.6.4 client still couldn't access the group calendar, but the other clients who were left at 10.6.3 had no problems in reading iCal Server (which is now running 10.6.4)

So this in my view should exclude a server-side bug.

The only workaround I found is to open iCal, discard the error messages, go on accounts, change the calendar URL back to its original format of

/principals/ _uids_/wiki-groupname/

then close the account window, right click on the calendar menu and hit "refresh all".

Group calendar will work until you quit iCal and restart it, in that case you need to repeat the process.

I hope this is fixed very soon

I am not finding even that work around fixes it. The moment I click "Refresh All" the server paths revert to the hex GUID which cannot be found.

We have two separate issues, fixing either will solve the problem:
1. The server actually responds to the GUID for the wiki calendar groups
2. The client uses the Wiki path rather than the GUID path


What was changed was the behaviour of #2. It broke because of the bug #1. Technically, the bug is #1, not #2, but the change to #2 caused the breaking of the calendar lookups.

Try to do it twice in rapid succession. Sounds ridiculous but after a reboot the workaround starts to work from the second try on. For me at least.

And I agree with you, although bug #1 is much older than the current update. I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.

CS8 wrote:
... I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.

Sorry to be the bearer of unfortunate news, but the above is true. Your intuition that this is unsupported was correct. True group calendaring is not a supported feature in Snow Leopard, and if it were, there would probably be a better user experience that didn't require you to manually hack paths around in the iCal prefs. In general, if you are relying on a behavior that is not documented, there is a good chance that it is unsupported / incidental behavior, as in this case.

The closest supported path for 'group calendaring' is to use delegation. We realize that group calendaring is an important feature, and has already been implemented for a good while in our trunk codebase, on macosforge. Please note that running trunk code is also not supported; I mention it only to indicate that we understand the importance of the feature.

-dre

This happened to us too. Maybe it's Apple's way of saying to go to Exchange? I hope not, but that's what'll happen here if I can't get this solved. 😟

Andre LaBranche1 wrote:

CS8 wrote:
... I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.

Sorry to be the bearer of unfortunate news, but the above is true. Your intuition that this is unsupported was correct. True group calendaring is not a supported feature in Snow Leopard, and if it were, there would probably be a better user experience that didn't require you to manually hack paths around in the iCal prefs. In general, if you are relying on a behavior that is not documented, there is a good chance that it is unsupported / incidental behavior, as in this case.

The closest supported path for 'group calendaring' is to use delegation. We realize that group calendaring is an important feature, and has already been implemented for a good while in our trunk codebase, on macosforge. Please note that running trunk code is also not supported; I mention it only to indicate that we understand the importance of the feature.

-dre

Well that's kind of garbage. Between no support for binding Windows 7 clients and now breaking a functionality that worked fine until the latest patch, I have to wonder why go through the pain of sticking with Snow Leopard Server. Obviously group calendaring works fine as you can do it through the wiki. The fact that Apple's own iCal client won't work when Sunbird or emClient will seems ridiculous.

Looks like you can still subscribe to group calendars using the iCal app.

I don't know about everybody else, but subscribing isn't enough for our organization.

We moved from Now Up To Date to iCal server with the introduction of 10.5, with the expectation of group calendar support continuing. When 10.6 came along, and we had to change the method used to utilize group calendars, we were still ok. But if Apple has permanently closed that door on us, we and I suspect a lot of other people, will be looking at non-Apple solutions.

Exchange is dirt cheap for education. And we need to replace our old QMail server anyway...

I think what has happened here is that a hack became a De facto standard. Now users are making it known how much they depended on this unsupported feature. So let's file enhancement/feature request bugs, then wait and see.