Also calendar server 2.4 does not have this behaviour but does not have all the features I was hoping for.
On 2013-03-07, at 12:18 PM, Robert Bruce 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 <rbr...@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 > > _______________________________________________ > calendarserver-users mailing list > calendarserver-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-users _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
