[CalendarServer-users] Calendar Server

[Andre LaBranche]

Hi Robert,

We'd like to help you get this figured out, but you're making it hard for us :) Please take the following to heart:

1) Please read each reply you receive on this thread in its entirety, and respond to all questions that are posed. For example, the second paragraph you quoted from Cyrus' reply hasn't been addressed (the one that begins: Is the account in your client one that has been present all the time since you did the upgrade?)

2) Please send all emails on this topic to the list and not to individual people; this helps everyone benefit from the shared knowledge, and lets us play tag team on dealing with this (and other) issues.

Thanks and cheers,
-dre


On Mar 7, 2013, at 9:18 AM, Robert Bruce <rbruce at celsiusinc.com> wrote:

> Hi I have been using multiple clients (different iCal version 4.0.4, 5.0.3) and different system and just created a new account to try to make sure... it's the same problem... 
> 
> It's not just for Deletes I have to do all operations twice... 
> 
> If I refresh iCal before each Move, Delete, etc... then it is ok, but not ideal solution.    
> 
> On 2013-03-07, at 12:09 PM, Cyrus Daboo wrote:
> 
>> Hi Robert,
>> 
>> --On March 7, 2013 at 12:04:56 PM -0500 Robert Bruce <rbruce at celsiusinc.com> wrote:
>> 
>>> ::ffff:192.168.1.38 - - [07/Mar/2013:12:03:02 -0400] "DELETE
>>> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
>>> cs HTTP/1.1" 412 157 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
>>> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=12.7
>>> ::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:02 -0400] "GET
>>> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
>>> cs HTTP/1.1" 200 705 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
>>> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=22.4
>>> 
>>> 
>>> 
>>> 
>>> Second try delete works...
>>> 
>>> 
>>> 
>>> ::ffff:192.168.1.38 - admin [07/Mar/2013:12:03:51 -0400] "DELETE
>>> /calendars/__uids__/admin/calendar/AE195B52-8AD1-4F43-BB6B-2298EC72E889.i
>>> cs HTTP/1.1" 204 0 "-" "DAVKit/4.0.3 (732.2); CalendarStore/4.0.4
>>> (997.7); iCal/4.0.4 (1395.7); Mac OS X/10.6.8 (10K549)" i=1 or=1 t=511.1
>>> 
>>> 
>>> 
>>> 
>>> The deletes that work are not followed by a GET...
>>> 
>> 
>> OK, so the client is doing a conditional DELETE request - i.e. it is asking the server to only do the DELETE if the resource on the server is unchanged from the one that the client originally cached. For some reason it is not, so a 412 error comes back, and the client reloads the resource using GET. The second DELETE then works fine.
>> 
>> Is the account in your client one that has been present all the time since you did the upgrade? If so, try removing the account from the client, then re-add it and let it resync all the data. Once it has done that, hopefully it will have the change state correctly cached and you won't see the double DELETEs (except for when a real change has taken place on the server that the client has not sync'd).
>> 
>> -- 
>> Cyrus Daboo
>