Closed Bug 581943 Opened 10 years ago Closed 6 years ago

"An error occurred when writing to the calendar XXX" when trying to dismiss reminders

Categories

(Calendar :: Provider: CalDAV, defect, major)

Lightning 1.0
x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: najtssob, Unassigned)

References

()

Details

(Whiteboard: [calconnect31])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; sl; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1

When I try to dismiss reminders in Lightning 1.0 beta 2 i get following error: 
"An error occurred when writing to the calendar XXX".

In my observations error appers almost everytime when there is a lot of reminders and ocasionly when there are just few of them. 
On this link is the SC of an error (http://www.shrani.si/f/l/Xv/4tvvjsd6/tbnapaka2.jpg).

I am using Zimbra 5.0.18 server with thunderbird 3.1 and lightning 1.0 beza 2.


 

Reproducible: Sometimes

Steps to Reproduce:
1. Setup a lot of reminders in zimbra
2. Start thunderbird with lightning
3. when reminder dialog pops up, try to dismiss them (dismiss all).
Actual Results:  
Error dialog pops up saying "An error occurred when writing to the calendar XXX".
And when you clik "OK" to close the error dialog it pops up again and again. 

Expected Results:  
It should dismiss reminders without error dialog poping up.

I have dozens of users suffering from this bug. Computers are all virtual machines on VMware ESX 4.0 and guest OS is win XP sp3.
Priority: -- → P2
Version: unspecified → Lightning 1.0b2
Summary: "" when trying to dismiss reminders → "An error occurred when writing to the calendar XXX" when trying to dismiss reminders
Message from error console:

Error: An error occurred when writing to the calendar Tarik Khalil! Error code: MODIFICATION_FAILED. Description: 
Source File: file:///D:/Documents%20and%20Settings/tkhalil/Application%20Data/Thunderbird/Profiles/3j6g6176.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///D:/Documents%20and%20Settings/tkhalil/Application%20Data/Thunderbird/Profiles/3j6g6176.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 1014

When I click to the link, I get error that file does not exists.
This also happens while trying to connect to exchange cal using davmail as proxy. Any linux distro will do, I've seen this on Fedora, RHEL and Ubuntu.

I believe this is duplicate of bug #579615
Please enable calendar.debug.log and calendar.debug.log.verbose in the advanced config editor and try dismissing again. In the error console you should see a lot of debug info, maybe there is something interesting just before the modification failed message.
hello there,

i am having this calender popup event notification error when trying to dismiss events or remind-me-again-in-x-mins.

nothing happens when i do the actions for the first time, and when i close the popup window (X icon on upper right of window, win32/winxp, Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0, 20110624125636) i see these duplicate event errors and so forth.

the whole bug only started ever since my (long-term) thunderbird got updated to 5.0 and upgraded its lightning/calendar plugin to /b4 as well.

no calendar/lightning errors of this kind were present with the old 3.x thunderbird and /b2 (or was it b3?) calendar just a few weeks ago.

i have even removed the calendar/lightning plugin completely (via the addon window/tab) and reinstalled it from there again. to no avail.

---------------
error console says:

Warning: There has been an error reading data for calendar: Home.  However, this error is believed to be minor, so the program will attempt to continue. Error code: 0x80004005. Description: generation too old for for modifyItem

Error: An error occurred when writing to the calendar Home! Error code: MODIFICATION_FAILED. Description: 
Source File: resource://calendar/modules/calUtils.jsm -> file:///C:/Documents%20and%20Settings/user01/Application%20Data/Thunderbird/Profiles/2zhecj5w.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 1061

----------------

long-term thunderbird means i have come a very long way using it, like thunderbird 2.x or so and also very old lightning entries (calendar/reminders), yearly events such as anniversaries birthdays and so forth.

this is really a pest and very annoying. what now?
thanks for helping and sorting out this bug and actually fixing the bug. hope i can be of some help. regards.
oh, btw, when clicking this error link in the error console, it is probably supposed to display the sourcecode of the module causing the error or something?

i am only getting empty new thunderbird windows when clicking there and the error console additionally logging this line:

Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURI]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: chrome://global/content/viewSource.js :: viewSource :: line 179"  data: no]

Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURI]"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: chrome://global/content/viewSource.js :: viewSource :: line 179"  data: no]

.....
btw, my calendar is a local file-based calendar, inside my thunderbird profile, on this winxp/win32 machine ever since. so no google, caldav, ldap or whatever external stuff going on with regards to the calendar.
I can confirm this bug still exists - it's been bothering me for quite some time. A possible explanation of what might go on behind the scenes is here: http://www.zimbra.com/forums/isync-caldav/28832-problem-deleting-changing-events-lightining.html#post209526

Like the OP I use Lightning/CalDAV/Zimbra. Here's the console log (I masked the iCal):


Error: An error occurred when writing to the calendar MSR! Error code: MODIFICATION_FAILED. Description: Status Code: 409, Resource conflict.

Source File: file:///C:/data/Mozilla/Profiles/Thunderbird/5b7tlk3v.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///C:/data/Mozilla/Profiles/Thunderbird/5b7tlk3v.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js
Line: 1065


Error: CalDAV: Unexpected status modifying item to MSR: 409

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20110805T115414Z
DTSTAMP:20110805T115414Z
UID:eb5458f2-d404-49b3-a6f3-60ba0364b324
SUMMARY:*******************
STATUS:CONFIRMED
ORGANIZER;CN=Marcel Stör:mailto:marcel.stoer***************
ATTENDEE;RSVP=TRUE;CN=***************;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT:mailto:*******
ATTENDEE;RSVP=TRUE;CN="*********";PARTSTAT=ACCEPTED;CUTYPE=RESOURCE;ROLE=NON-PARTICIPANT:mailto:********
X-MOZ-LASTACK:20110805T115414Z
DTSTART;TZID=Europe/Berlin:20110805T133000
DTEND;TZID=Europe/Berlin:20110805T140000
LOCATION:***************

CLASS:PUBLIC
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
TRANSP:OPAQUE
SEQUENCE:0
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
Could it be that setting itip.disableRevisionChecks=true (http://mxr.mozilla.org/comm-central/source/calendar/base/public/calICalendar.idl#159) is a work-around for this issue?
The exact same error sometimes occurs when accepting an invitation:

Error: An error occurred when writing to the calendar MSR! Error code: MODIFICATION_FAILED. Description: Status Code: 409, Resource conflict.
OS: Windows XP → All
(In reply to marcel from comment #8)
> Could it be that setting itip.disableRevisionChecks=true
> (http://mxr.mozilla.org/comm-central/source/calendar/base/public/
> calICalendar.idl#159) is a work-around for this issue?

It seems that it solved it for me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Zbigniew Braniecki [:gandalf] from comment #10)
> (In reply to marcel from comment #8)
> > Could it be that setting itip.disableRevisionChecks=true
> > (http://mxr.mozilla.org/comm-central/source/calendar/base/public/
> > calICalendar.idl#159) is a work-around for this issue?
> 
> It seems that it solved it for me.

Where did you set this value?
(In reply to Dustin Ruckman from comment #11)
> (In reply to Zbigniew Braniecki [:gandalf] from comment #10)
> > (In reply to marcel from comment #8)
> > > Could it be that setting itip.disableRevisionChecks=true
> > > (http://mxr.mozilla.org/comm-central/source/calendar/base/public/
> > > calICalendar.idl#159) is a work-around for this issue?
> > 
> > It seems that it solved it for me.
> 
> Where did you set this value?

Preferences -> Advanced -> Config Editor
If itip.disableRevisionChecks is not yet there you do
right mouse click -> New -> Boolean set itip.disableRevisionChecks as property name and true as property value.
(In reply to marcel from comment #12)
> (In reply to Dustin Ruckman from comment #11)
> > (In reply to Zbigniew Braniecki [:gandalf] from comment #10)
> > > (In reply to marcel from comment #8)
> > > > Could it be that setting itip.disableRevisionChecks=true
> > > > (http://mxr.mozilla.org/comm-central/source/calendar/base/public/
> > > > calICalendar.idl#159) is a work-around for this issue?
> > > 
> > > It seems that it solved it for me.
> > 
> > Where did you set this value?
> 
> Preferences -> Advanced -> Config Editor
> If itip.disableRevisionChecks is not yet there you do
> right mouse click -> New -> Boolean set itip.disableRevisionChecks as
> property name and true as property value.

I am not sure, but shouldn't the key be prepended by 'calendar.'? I have several other config keys  'calendar.itip.*'.
Version: Lightning 1.0b2 → Trunk
Duplicate of this bug: 606228
Duplicate of this bug: 579615
So I was able to reproduce right now with the logs enabled :

>Error: An error occurred when writing to the calendar Mozilla Calendar! Error 
>code: MODIFICATION_FAILED. Description: Status Code: 409, Resource conflict.
>Source File: resource://calendar/modules/calUtils.jsm -> file:///Users/ludo/Library
>/Thunderbird/Profiles/hwprdu9c.default/extensions/%7Be2fda1a4-762b-4020-b5ad-
>a41df1933103%7D/calendar-js/calCalendarManager.js Line: 1108

There's a warning just before :
>Warning: There has been an error reading data for calendar: Mozilla Calendar.  
>However, this error is believed to be minor, so the program will attempt to 
>continue. Error code: DAV_PUT_ERROR. Description: There was an error storing the 
>item on the server.

And a nice very long error just before that looks like comment 7

>Error: CalDAV: Unexpected status modifying item to Mozilla Calendar: 409
>BEGIN:VCALENDAR
>PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
>VERSION:2.0
>BEGIN:VTIMEZONE
>TZID:Europe/Berlin
>X-LIC-LOCATION:Europe/Berlin
>BEGIN:DAYLIGHT
>TZOFFSETFROM:+0100
>TZOFFSETTO:+0200
>TZNAME:CEST
>DTSTART:19700329T020000
>RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
>END:DAYLIGHT
>BEGIN:STANDARD
>TZOFFSETFROM:+0200
>TZOFFSETTO:+0100
>TZNAME:CET
>DTSTART:19701025T030000
>RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>END:STANDARD
>END:VTIMEZONE
>BEGIN:VEVENT
>LAST-MODIFIED:20111018T084323Z
>DTSTAMP:20111018T084323Z
>UID:2ef385c6-7d16-4b51-9a3f-1bec8354823c
>SUMMARY:Seminaire aristote web 1.0
>STATUS:CONFIRMED
>ORGANIZER;CN=Ludovic  Hirlimann:mailto:lhirlimann@mozilla.com
>X-MOZ-LASTACK:20111018T084323Z
>DTSTART;TZID=Europe/Berlin:20111012T080000
>DTEND;TZID=Europe/Berlin:20111012T200000
>LOCATION:inconnu
>CLASS:PUBLIC
>X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
>TRANSP:OPAQUE
>SEQUENCE:0
>X-MOZ-GENERATION:1
>BEGIN:VALARM
>ACTION:DISPLAY
>TRIGGER;VALUE=DURATION:-PT5M
>DESCRIPTION:Reminder
>END:VALARM
>END:VEVENT
>END:VCALENDAR
(In reply to Philipp Kewisch [:Fallen] from comment #17)
> Likely this is bug 496897?

Yep I'll dup the other way around as this as more people on the cc list.
Duplicate of this bug: 496897
I wouldn't say this is entirely the same as bug 496897 unless it only occurs with multiple occurrences of the same repeating item shown in the alarm dialog. I have a patch in testing that I'll be posting shortly that addresses that specific case - if it's OK by you I don't think that bug should be duped against this quite yet.
Marking dependent on bug 496897 - we'll see if it solves this issue.
Depends on: 496897
I've just upgraded to Thunderbird 8.0 with Lightning 1.0 and this bug occurred. I've never experienced it before - using Thunderbird and Lightning for several years.
I also had this bug with Thunderbird 7.0.1 and lightning 1.0b7. Adding boolean itip.disableRevisionChecks (not calendar.itip.disableRevisionChecks) and setting it to "true" solved it for me (I also had to declare the calendar to be writable in the properties, it was set to "write protected" repeatedly).

In my case, the calendar file was on an external ftp server.
(In reply to nemo from comment #23)
> I also had this bug with Thunderbird 7.0.1 and lightning 1.0b7. Adding
> boolean itip.disableRevisionChecks (not calendar.itip.disableRevisionChecks)
> and setting it to "true" solved it for me (I also had to declare the
> calendar to be writable in the properties, it was set to "write protected"
> repeatedly).
> 
> In my case, the calendar file was on an external ftp server.

Which file should I edit?
Thank you.
(In reply to nemo from comment #23)
> I also had this bug with Thunderbird 7.0.1 and lightning 1.0b7. Adding
> boolean itip.disableRevisionChecks (not calendar.itip.disableRevisionChecks)
> and setting it to "true" solved it for me

Is this a global setting in your case i.e. the preference name you set really is "itip.disableRevisionChecks" or is it a per-calendar setting an the full name is "calendar.registry.<some_UUID>.itip.disableRevisionChecks"?
Side note for those who are affected by this bug and whose CalDAV server is Zimbra...

In the Zimbra web client (>= v6 only?) under Preferences -> Calendar -> General there's a checkbox labeled "Automatically add received appointments to calendar". You might want to turn it off. Otherwise Zimbra automatically processes the invitation and thereby modifies the timestamp which in turn causes the conflict with Lightning.
Marcel, thats a great tip with the timestamps, it may help with bug 700644.
(In reply to marcel from comment #25)
> Is this a global setting in your case i.e. the preference name you set
> really is "itip.disableRevisionChecks" or is it a per-calendar setting an
> the full name is "calendar.registry.<some_UUID>.itip.disableRevisionChecks"?

I took an extra effort to describe it's *not* the calendar.itip.disableRevisionChecks setting mentioned in a different post. I don't see myself able to extend this explanation to every thinkable setting, declaring it's not that one either. The setting is itip.disableRevisionChecks, really itip.disableRevisionChecks, nothing else, nothing added, nothing removed! :)
But it's an interesting question, would I be able to limit that setting to one itching calendar? But I'd have to find out some_uuid?

(In reply to Honza from comment #24)
> Which file should I edit?
> Thank you.

Not a file. See Comment #13.
(In reply to Honza from comment #24)
> Which file should I edit?

Scuseme, actually, originally #12. Comment #13 only quotes the description.
This problem just appeared for me for the first time when I upgraded to Thunderbird 8.0 and Lightning 1.0 (in Win7 x64 Professional).  I tried setting itip.disableRevisionChecks to true (it didn't exist), and it didn't have an immediate effect. I restarted Thunderbird, and created a dummy reminder, which I was just able to successfully snooze without an error.
The fix above did not fully work. The reminder from yesterday came up again today (I guess closing the window didn't dismiss it), and when I tried to postpone it an hour, I got the same error.
An error occurred when writing to the calendar Home!
Error code: MODIFICATION_FAILED
I agree with Erik. Applied the fix but next reminders both failed with the same error. This is running TB 8.0 and Lightning 1.0 on openSUSE 11.4, KDE 4.7.3.
Forgot to mention that since this problem started, for a totally different reason, I've had to create a new profile and import the calendar - having first exported from the old profile - but this has had no beneficial effect either.
(In reply to Graham P Davis from comment #32)
> I agree with Erik. Applied the fix but next reminders both failed with the
> same error. This is running TB 8.0 and Lightning 1.0 on openSUSE 11.4, KDE
> 4.7.3.
Is this problem exclusively occurring with the cached mode or does it also happen with the uncached mode as well?
:redDragon, I see where you're going here...you're trying to find out whether the behavior reported by Graham and Erik should be better tracked with bug 700644 or here.

In my case the cache is disabled.
I've no idea whether my cache is enabled or disabled. I've looked but obviously in the wrong place. Search on "help" had one successful result which had nothing remotely useful.
You can double click on the calendar in the left hand side and open up the calendar properties dialog (or right click -> properties). from there you can check if the calendar is in cached mode by looking at the state of the check box next to Cache.
Thanks, Mohit. "Cache (experimental)" is greyed out. 
Marcel, I've had a look at #700644 and it doesn't seem the same as I'm not using a remote calendar.

This bug is a bit erratic. I had a reminder this morning that needed a "dismiss" and it worked OK. This was for one of the reminders that created an error yesterday. Created a new event just now and delaying it has also worked.
That bug has actually been present for a long time and is not related to the cache mode.
Version: Trunk → Lightning 1.0
If it helps any, I have this bug on Mac OSX, Thunderbird 8.0 with Lightning 1.0. I only have one calendar and it's properties are: 
Switch this calendar on (checked)
Location: moz-storage-calendar://
Email: my gmail address
Read only: not checked
Show alarms: checked
Cache: greyed out, not checked

I have a lot of recurring events that bring up alarms, one that does so every day and others that are interspersed throughout the week.

Hope that helps.
I am also getting this for quite sometime. I am on Ubuntu 11.10, Thunderbird 8.0 with Lightning 1.0. Have all the latest patches and fixes.
To anybody who could reproduce this bug in the past: Is this still an issue using the recently released Lightning 1.1 (compatible with Thunderbird 9)?
(In reply to Martin Schröder [:mschroeder] from comment #42)
> To anybody who could reproduce this bug in the past: Is this still an issue
> using the recently released Lightning 1.1 (compatible with Thunderbird 9)?

I can't recall exactly when I updated to TB9 and Lightning 1.1, probably about ten days ago, but I've noticed that I've had no repetition of this problem so far. It's a bit early to be sure so I'm keeping my fingers crossed.
I haven't seen this problem since upgrading to TB9 and Lightning 1.1, but I only upgraded 5 days ago, and this Lighning bug was hitting me only once every couple weeks, primarily with very old recurring alarms.
(In reply to Erik Harris from comment #44)
> I haven't seen this problem since upgrading to TB9 and Lightning 1.1, but I
> only upgraded 5 days ago, and this Lighning bug was hitting me only once
> every couple weeks, primarily with very old recurring alarms.
Which is a good sign that it was fixed with a certain bug that was fixed between 1.0 and 1.1. It was specific to very old alarms.

I'm going to mark this WFM for now, please reopen if it occurs again.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
I am still getting this error after I had updated to TB9 and Lightning 1.1. The error occured, when I tried to dismiss a reminder that I set about two weeks ago. 

The reminder popped up today, I tried to dismiss all and didn't check the result any further. Then I opened Zimbra in the Browser and many reminders popped up, which partly had been dismissed in TB8 (!) yesterday. The last reminder was the mentioned one.

After I switched back to TB I saw that the notification was still active and I couldn't "dismiss all" - the button didn't trigger anything. I closed the window (X) and immediately the message "An error occured...writing..." with ERR 409 was displayed. 

> It was specific to very old alarms.

I will check if it appears again for reminders created in TB9.

Console-Log:

02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   Error: CalDAV: Unexpected status modifying item to <Cal Name>: 409
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:VCALENDAR
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   VERSION:2.0
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:VTIMEZONE
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZID:Europe/Berlin
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   X-LIC-LOCATION:Europe/Berlin
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:DAYLIGHT
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZOFFSETFROM:+0100
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZOFFSETTO:+0200
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZNAME:CEST
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DTSTART:19700329T020000
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:DAYLIGHT
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:STANDARD
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZOFFSETFROM:+0200
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZOFFSETTO:+0100
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TZNAME:CET
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DTSTART:19701025T030000
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:STANDARD
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:VTIMEZONE
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:VEVENT
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   CREATED:20120101T171424Z
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   LAST-MODIFIED:20120102T081954Z
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DTSTAMP:20120102T081954Z
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   UID:da4f107f-8fbe-cc49-a2c8-128db143be91
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   SUMMARY:<Summary here>
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   STATUS:CONFIRMED
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   X-MOZ-LASTACK:20120102T081954Z
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DTSTART;TZID=Europe/Berlin:20120102T093000
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DTEND;TZID=Europe/Berlin:20120102T100000
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   CLASS:PUBLIC
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TRANSP:OPAQUE
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   X-MICROSOFT-DISALLOW-COUNTER:TRUE
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   SEQUENCE:0
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   X-MOZ-GENERATION:1
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   BEGIN:VALARM
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   ACTION:DISPLAY
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   TRIGGER;VALUE=DURATION:-PT15M
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   DESCRIPTION:Mozilla Standardbeschreibung
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:VALARM
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:VEVENT
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   END:VCALENDAR
02.01.12 09:20:00   [0x0-0x80d80d].org.mozilla.thunderbird[30100]   Warning: Fehler beim Lesen von Daten für Kalender: <Cal Name>. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Fehlercode: DAV_PUT_ERROR. Beschreibung: Beim Speichern des Eintrags auf dem Server ist ein Fehler aufgetreten.
(In reply to jotbe from comment #46)
> I am still getting this error after I had updated to TB9 and Lightning 1.1.
> The error occured, when I tried to dismiss a reminder that I set about two
> weeks ago. 
> 

The problem still occurs with new appointments. Sometimes it helps to disable the cache of the calendar.
This update (seems) to solve all my issues.
I am getting this error repeatedly.  Have upgraded to TB 9.0 and Google Provider 1.1
Problem is easily reproducible.  Simply create a repeating task, then try to edit one instance (such as CANCEL or EVENT or almost any other mod).
We're also seeing this error with multiple users.  We're running Thunderbird 14.0; does anyone know if 17.0 or later versions have resolved this?
Oops, I should probably have referred to the Lightning version, not the TB version.  We're running 1.9.1 (though users can update their plugins on their own, so some users may have different versions).
I'm running Thunderbird 17.0.8 (on Mac OS 10.8.4) with Lightning 1.9.1, and I still encounter this write to calendar error issue.
Issue still happens on Thunderbird 24.0 (on Mac OS 10.8.5) with Lightning 2.6...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
also again broken on 

thunderbird-17.0.8-1.fc19.x86_64
thunderbird-lightning-1.9.1-2.fc19.x86_64

on fedora 19. I had to switch to exchange 2013, it might also make the difference.
Priority: P2 → --
Issue still happens on Thunderbird 31.0 (on Ubuntu 14.04 LTS) with Lightning 3.3.
To be honest I'd love to close this bug. It seems there are a lot of different issues mentioned in the past 55 comments, some applying to the Provider for Google Calendar, others to CalDAV. Its hard to figure out what the real issue is here and which one of the "me too" comments are related to which issue. The original issue is:


With a Zimbra CalDAV Server...
* Create a recurring event, with some exceptions (e.g. moved to a different time)
* Make sure alarms fire for more than one occurrence and are shown in the alarm dialog
* Dismiss all alarms at once


Result:

* a 409 conflict error occurs and is mentioned in the error console
* no dialog to handle the conflict

Expected

* The alarms dismissals are coalesced
* No conflict occurs
Whiteboard: [calconnect31]
I on the other hand haven't seen this for a longish while running against DAViCal.
Ok, I've done some extensive testing on a zimbra server and could not trigger this case. Therefore I am closing this bug. If this is still an issue, please file a new bug.
Status: REOPENED → RESOLVED
Closed: 8 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.