Closed
Bug 326332
Opened 19 years ago
Closed 18 years ago
Event creation in ics calendar fails after backup problems.
Categories
(Calendar :: Internal Components, defect)
Calendar
Internal Components
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ssitter, Unassigned)
Details
(Whiteboard: [swag:.5d][maybe have patch])
Attachments
(1 file)
1.39 KB,
patch
|
mattwillis
:
first-review+
jminta
:
second-review+
|
Details | Diff | Splinter Review |
Event creation in ics calendar fails after backup problems. 1. Start Sunbird with a new profile. 2. Delete the default storage calendar. 3. Create an ics calendar (I tested with a remote calendar at file:///c:/test.ics) 4. Create an event via drag'n'drop in week view. The following error appeared in console: Backup failed in asyncOpen:[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.asyncOpen]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: file:///D:/Programme/sunbird/components/calICSCalendar.js :: anonymous :: line 683" data: no] 5. Create more events. In %SunbirdProfile%\backupData backup files are created named calBackupData_xxxx_edit-1.ics to calBackupData_xxxx_edit-3.ics. After creation of the next event the following error is shown four times in JavaScript console: Error: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.remove]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: file:///D:/Programme/sunbird/components/calICSCalendar.js :: purgeBackupsByType :: line 548" data: no] Afterwards it is not possible to create new events. Restart of Sunbird required. Tested on windows with 2006-02-07 sunbird trunk build.
Comment 1•19 years ago
|
||
I've seen at least the access denied thing not too long ago; confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•18 years ago
|
||
Is this still a bug? I can't reproduce on linux using comment #0.
Reporter | ||
Comment 3•18 years ago
|
||
(In reply to comment #2) I can still reproduce using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060713 Sunbird/0.3a2+. Error: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.remove]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: file:///D:/sunbird/components/calICSCalendar.js :: purgeBackupsByType :: line 620" data: no]
Comment 4•18 years ago
|
||
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
Comment 5•18 years ago
|
||
I typically have to restart Sunbird on Windows and Mac on the order of 10 times a day. This generally happens I edit multiple events in quick successionon a WebDAV calendar. There are really two bugs here: one is probably in nsLocalFile* and the other is that we should catch any errors thrown by nsLocalFile* and do something reasonable. I believe the bug in nsLocalFile is already filed.
Flags: blocking0.3?
OS: Windows 2000 → All
Hardware: PC → All
Updated•18 years ago
|
Flags: blocking0.3? → blocking0.3+
Updated•18 years ago
|
Whiteboard: [swag:.5d]
Comment 6•18 years ago
|
||
I still can't reproduce this bug, so this is just a best-guess at a patch. The idea here is that failing to remove a file is the least severe kind of error we can have. (When were more backups not a good thing?) Also, we'll eventually get to clear it up, on the next round of backups.
Attachment #233028 -
Flags: second-review?(dmose)
Attachment #233028 -
Flags: first-review?(mattwillis)
Updated•18 years ago
|
Whiteboard: [swag:.5d] → [swag:.5d][maybe have patch]
Comment 7•18 years ago
|
||
Comment on attachment 233028 [details] [diff] [review] maybe patch This at least catches the failure. That's good. Should we at least send this to the error console rather than swallowing it entirely?
Comment 8•18 years ago
|
||
(In reply to comment #7) > (From update of attachment 233028 [details] [diff] [review] [edit]) > This at least catches the failure. That's good. > > Should we at least send this to the error console rather than swallowing it > entirely? > As I said in my comment, this strikes me as one of the absolutely least critical failure modes imaginable. At best, I think we should dump it to the regular console. I'm open to arguments why that's wrong.
Comment 9•18 years ago
|
||
Comment on attachment 233028 [details] [diff] [review] maybe patch Okay. I don't think this will hurt anything, and if it keeps people from having to restart, then it's at least forward progress. r=lilmatt
Attachment #233028 -
Flags: first-review?(mattwillis) → first-review+
Comment 10•18 years ago
|
||
Comment on attachment 233028 [details] [diff] [review] maybe patch r=dmose
Attachment #233028 -
Flags: second-review?(dmose) → second-review+
Comment 11•18 years ago
|
||
Patch checked in. I'm marking this fixed since it's on the blocking radar. If there are other problems, please file followups. Let's reserve this bug for backup-errors of the severity listed here.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•18 years ago
|
||
VERIFIED with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060901 Calendar/0.3a2+
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•