Closed Bug 218983 Opened 22 years ago Closed 19 years ago

Adding new event on remote calendar destroys entire calendar

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: gobbel, Assigned: mostafah)

References

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 I tried to create a new event on a remote calendar, set up with "publish automatically", and hosted on my personal Linux server at home, using SSL and Apache with mod_dav. I got a "this doesn't seem to be a valid file" error, showing the URL for the calendar, but no data. Following this, both the remote and local files are zero-size. The entire calendar is gone, with no backups that I can find. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Create new event on a remote calendar. Actual Results: It usually works.
More info: I also got an error dialog that wouldn't go away. I had to force-quit Mozilla to get the calendar working again. So this caused a crash, as well as losing one whole calendar. I see a couple of other bugs that appear to be related. What I think happened: 1. Calendar has auto-publish checked, so editing causes a download. The download fails. 2. inserting new event fails, because the zero-sized calendar that results from the failed download is not valid. 3. Zero-sized calendar is uploaded. Upload SUCCEEDS. 4. The calendar has now been wiped out on both client and server machines.
I had a similar effect. Using apache mod_dav and me and a colleague were testing sharing our calendar, i.e. we can look at and read each others calendars. We we're quite impressed for like 1 hour and then one of the files got zero'ed. Here's what happened. I removed an entry from my calendar. But did not publish. He went along and changed the content of the same entry and published it. I try and publish and the calendar hangs and eventually tells me that the file is invalid. The file was actually invalid as somewhere in these steps the file got zeroed. Hope this helps...
Here's how I can reproduce this: I'm running an Apache webserver with mod_dav, I can reproduce this using the front end on Linux or XP. 1. Create a calendar with 1 or more events. 2. Publish the calendar to the remote server. 3. Delete the events from the remote calendar so that there are zero events in it. 4. Create a new event, you will get an error: "This doesn't appear to be a valid file. Here's what I got back from http://<server url> Result: When you examine the .ics file on the server you will see that it is zero length with no content. I'm new to this but it seems to me that it should have: BEGIN:VCALENDAR VERSION :2.0 PRODID :-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN END:VCALENDAR
Reporter, Would you please try to reproduce this bug using the latest builds?
I just tried to reproduce this using the steps that Ed Robbins describes, and the 20041112 build. The behavior is exactly as he describes it--"not a valid file", a zero-length file on the server. It appears that the bug is still there--I can't see any change from what happened with previous versions. I will keep trying to reproduce the exact original situation that I ran into.
*** Bug 272852 has been marked as a duplicate of this bug. ***
Reproduced with Calendar 2005-1-11 IIS 5.0 You can get around this by: 1. Remove the "automatic sync" checkbox. 2. Add one event. 3. Manually "publish entire calendar". 4. Restore the "automatic sync" checkbox. As long as there is at least one event in the calendar, it is fine.
I confirm that as long that there is 1 calendar entry, it fine, but if you delete them all, it .ics file is empty, and calendar say the file is invalid. I had to create a dummy entry locally, and paste it to the server file, then besure to always keep 1 item in my calender
*** Bug 279632 has been marked as a duplicate of this bug. ***
I think bug 271305 is a duplicate of this. A wild guess is that the provider (http://lxr.mozilla.org/mozilla/source/calendar/providers/ics/calICSCalendar.js) receives a calendar with one event and simply overwrites the destination calendar. The right routine should be something like: - retrieve the remote calendar - insert the event into it - publish again Also, as the author of the ics provider points out in line 156 the parsing is too brutal because it ignores all errors instead of handling them. Don't know if it's a bug, but it's a safe way to lose icalendar components without any hint of what went wrong (if the source calendar file isn't well-formed, that is).
(In reply to comment #10) Come to think of it, the "Publish single event" feature do what it's supposed to. Since there's no remote server service to merge the single event into the remote calendar file, "Publish single event" means "Publish an iCalendar file with one VEVENT component in it". The bug here is that the remote filename defaults to the same filename as the calendar file with the event in it. Maybe "publish single event" should prompt the user asking for a filename and explain what Publish single event means.
Isn't this a duplicate of Bug 271305?
*** Bug 271305 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
I'm using Sunbird version 0.2 (the release notes from 0.3 alpha1 scared me off). This has been a chronic problem for a group of 4 users in my company all using WinXP Pro. My remote calendar (on my server using WebDAV) just disappeared when I acknowledged an alarm. In the past, I have been able to salvage the calendars in question. I uninstall and reinstall the calendar program, and resubscribe to the remote calendars. Aside from this bug and the inability to sync with Palm, I LOVE Sunbird.
needs dataloss keyword
Keywords: dataloss
The similar problem: Remote: WebDAV for Apache + stunnel for SSL When the new event is added and sunbird closed after 1 second (copying of the whole calendar takes about 2seconds), the remote calendar is broken - half of it is ok, but it ends in none closed section in the middle of the file. -- migi
(In reply to comment #16) > The similar problem: > > Remote: WebDAV for Apache + stunnel for SSL > > When the new event is added and sunbird closed after 1 second (copying of the > whole calendar takes about 2seconds), the remote calendar is broken - half of > it is ok, but it ends in none closed section in the middle of the file. I've spun this particular incarnation off to its own bug, bug 328810.
dmose and I think this has probably been fixed in the new backend. If you can reproduce this in Sunbird 0.3a2, please reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.