Closed Bug 393449 Opened 18 years ago Closed 17 years ago

Dismissing alarm deletes ics file

Categories

(Calendar :: Alarms, defect)

Product:
Calendar
Component:
Alarms
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mike, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Lightning 0.5 If I dismiss and alrm my ics file is deleted. ics file is stored on a webdav server. I have seen other weird delete/truncation behavior but have not been able to reproduce. Had no such problems in previous releases. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I've seen what appears to be the exact same behavior. I've got two Debian GNU/Linux clients running Lightning 0.5 in Thunderbird 2.0.0.6 (20070728). They're connecting to an Apache 1.3 webdav server that's serving a single .ics calendar file. When one client dismisses an alarm (and possibly at other times as well), the .ics file on the webdav server gets truncated down to exactly 8192 bytes (8k). This does not happen every time an alarm is dismissed, but it happens often enough to be fairly problematic.
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Summary: Dismiss alarm delete ics file → Dismissing alarm deletes ics file
I have the same problem, but it occurs on startup of Thunderbird (version 2.0.0.9 (20071031)) with Lightning (0.7). Calendars are stored on a Webdav server (Apache 2.0.54 on Fedora 4), the same server hosts the mailbox through IMAP. Client is Windows XP with latest updates. When an event pops up during startup of Thunderbird and I dismiss it, Thunderbird goes dead. The inbox refreshing ( tagging and moving spam ) just stops. I can close the application but the process doesn't exit and has to be killed manually. When I restart Thunderbird, the calendar is empty. When I check the server, the .ics file is gone. This has happened several times over the last weeks. It seems the problem occurs only when there is a significant amount of new mail to be downloaded and processed and the reminder pops up and is dismissed while Thunderbird is busy checking for spam. As a workaround I close the reminder dialog by clicking the cross at the top-right corner of the window. So far, this has prevented the issue from occuring.
I too have tried working around the problem by closing the reminder window forcibly rather than clicking "dismiss". However, I don't believe this actually modifies the .ics file on the server to dismiss the event, so the reminder just pops up again later. And if you have several events, and you never actually dismiss any of them with the "dismiss" button, you'll eventually have a screen full of events pop up that Lightning wants you to dismiss. So simply avoiding the "dismiss" button is of marginal utility as a workaround.
We have done quite a bit of work on alarms in the upcoming 0.8 release. Would one of you mind re-testing this with the 0.8 RC1 candidate and see if the problem has been fixed? I've also asked the calendar-qa team to look more deeply into this issue. You can pick up the RC1 here: http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/0.8-candidates/rc1/
It's important to know: do you use any kind of http-Proxy-server in your LAN?
I'll download and start using the 0.8 RC1 on all computers right now. However since this is an intermittent bug, it can sometimes take several weeks to reoccur with 0.7. Of course if it does reoccur with 0.8 RC1, I'll post here with details immediately. I'm not using any kind of http-proxy-server in my LAN.
I'll try 0.8 RC1 as well. I'm not using any kind of proxy server either.
Here's an update. After over three weeks of using 0.8 RC1 in the same sort of setup I've been using all along, the bug has not once reoccurred.
Marnix, have you experienced the problem with 0.8? Can we mark this bug as WFM after comment#8?
I have experienced this a couple of times since upgrading to 0.8. Thunderbird appears to 'hang' and the calendars disappear (they all seem blank). By hanging I mean there is a Thunderbird process that won't go away until I kill it from the task manager. I found out about this because all my calendars disappeared. So I closed thunderbird and restarted it. That didn't help. Looking at the process list I found the thunderbird process. At the time of the problem the webserver reports: [Sun Apr 13 17:27:30 2008] [error] [client 10.0.1.147] Could not get next bucket brigade [500, #0] After that the calender file is gone: [Sun Apr 13 17:28:51 2008] [error] [client 10.0.1.147] File does not exist: /var/www/webdav/marnix/marnix.ics Some research on Google seems to indicate that the server error could be caused by overlapping webdav calls. The webserver access log shows a GET and a PUT request shortly after one another: 10.0.1.147 - marnix [13/Apr/2008:17:25:27 +0200] "GET /webdav/marnix/marnix.ics HTTP/1.1" 200 83934 10.0.1.147 - marnix [13/Apr/2008:17:25:29 +0200] "PUT /webdav/marnix/marnix.ics HTTP/1.1" 500 616 A point of interest may be that this only occurs when I'm using calendars over VPN connection. I haven't experienced any problems with a direct network connection.
I found this in a mailing list: > "bucket brigades" are a construct used inside Apache to carry data from one > module to the next. Check that there are no data size limits configured > inside Apache itself (or inside one of the modules that interact with SVN). It seems this might be a server issue, there is no way Sb/Ltn will be able to send less data, other than maybe using compression, but I believe if the Accept-Encoding header is sent, then compression will be used automatically.
Philipp: I found the same info and checked this on the server. There is no such limitation in effect. In fact, the calendar works just fine (most of the time) even with larger files than this one (82 Kb). I've just been trying to reproduce the problem. I've tried the following several times and it always reproduces: 1. Start Thunderbird 2. Switch to calendar (icon at the bottom left) 3. Add an event, leave all the default values, click 'Save and close' 4. Dismiss notification 5. Switch to mail (icon at the bottom left) 6. Select a large folder (trash for example) The effect is that thunderbird goes to 50% CPU (not 100% due to hyperthreading on my system). The progress bar keeps spinning. The UI is responsive in that I can switch between mail and calendar and open mail folders, but the calendar that was modified is not showing any entries and the folders are not updated. The file on the server is still there. 7. Close thunderbird The process remains active and at 50% CPU 8. Kill thunderbird The process terminates, the calender file on the server is deleted.
Marnix, are you using secure connections to the IMAP server and to the remote calendar server? Also, you said that the problem mostly happens when you start Thunderbird. Does the problem disappear at startup if you disable the Thunderbird option to check for new mail at startup? Sorry to keep banging the same drum, but this bug could also be caused by the same thing as bug 390036, bug 428522, and maybe bug 422618. According to this bug report, the problem has existed since at least Lightning 0.5.
Pete, I'm using https for the calendar and imap with SSL. I've checked the reports for the bugs you named and it looks like they are pretty much the same issue. In the reproduction I posted (comment #12) I deliberately tried to make thunderbird access the calendar and e-mail at the same time. This always causes the issue, no matter if thunderbird is starting up or has been running for hours. Disabling the option to check for new mail at startup is just delaying the inevitable in my case. So, what I've tried is to disable SSL for e-mail. To my surprise that seems to fix the problem. I'll keep testing for a couple of days to see if this really prevents the problem from occurring.
Resolving as WORKSFORME per Comment #8. Additional issue reported by Marnix is tracked by bug 390036.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.