If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

app thinks deleted local folder is still there after restart, then creates undeletable "mbox folder"

RESOLVED FIXED

Status

MailNews Core
Backend
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: myk, Assigned: Bienvenu)

Tracking

({fixed-aviary1.0})

Trunk
x86
Linux
fixed-aviary1.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
If I delete a folder from my Local Folders account, restart, and attempt to
create a new folder with the same name, the app complains "A folder with that
name already exists.  Please enter a different name.", but when I restart again
the folder appears, is undeletable, and is represented in my <profile
dir>/Mail/Local Folders directory by a folder rather than an mbox file.

Steps to Reproduce:

1. create new local folder "foo";
2. delete "foo";
3. quit and restart;
4. attempt to create new local folder "foo";
5. quit and restart;
6. empty trash (so original "foo" gets deleted from trash);
7. attempt to delete "foo";

Expected Results: I can create a new folder in step 4, but failing that, the
folder doesn't appear after step 5, or if it does I can delete it.

Actual results: When I attempt to create a new folder in step 5, the first time
I press the OK button in the New Folder dialog nothing happens and the following
message appears on the JavaScript console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x8055000c [nsIRDFCompositeDataSource.DoCommand]"  nsresult: "0x8055000c
(<unknown>)"  location: "JS frame :: chrome://messenger/content/mailCommands.js
:: DoRDFCommand :: line 7"  data: no]

The second time I press the OK button the app complains "A folder with that name
already exists.  Please enter a different name." and the following message
appears on the JavaScript console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80550013 [nsIRDFCompositeDataSource.DoCommand]"  nsresult: "0x80550013
(<unknown>)"  location: "JS frame :: chrome://messenger/content/mailCommands.js
:: DoRDFCommand :: line 7"  data: no]

After restarting, the folder appears again, but when I try to delete it nothing
happens, and if I look in my profile directory the folder is represented in
<profile dir>/Mail/Local Folders/ by an empty directory rather than an mbox file.

The problem doesn't occur if I delete the folder and then attempt to recreate it
without restarting.  It's as if the deletion isn't getting written to the
datastore (panacea.dat?), so all record of the deletion is lost once the app is
shut down, causing the app to think the folder still exists upon restart, which
causes the mbox file to get created incorrectly when requested.

Tested on Thunderbird latest nightly (2004-06-24).
(Assignee)

Comment 1

13 years ago
taking - there are some dups of this out there, I think.
Assignee: sspitzer → bienvenu
(Assignee)

Comment 2

13 years ago
I believe this is caused by a failure to delete the .msf file at some point -
this prevents us from re-creating the folder.

I believe the failure to delete the folder might have to do with crashing on
shutdown, before we can write out panacea.dat, though I'm not sure about that.
If that is the case, it might be that the stale data in panacea.dat causes
problems when we recreate the folder and then delete it.
(Assignee)

Comment 3

13 years ago
Created attachment 154670 [details] [diff] [review]
proposed fix

this is more of a recovery from an earlier bug than a fix for the underlying
cause - if you try to create a folder and there's already a .msf file, we'll
just ignore the .msf file (it's out of date, so it will get blown away soon)
and allow folder creation to continue. This fixes the cascacding of errors.

I also added a null check for path because I encountered a null path at some
point in my debugging this.

I'll still try to figure out why .msf files sometimes remain after a folder is
deleted - I know that the reason is that someone is holding onto the .msf file,
but I don't know who.
(Assignee)

Updated

13 years ago
Attachment #154670 - Flags: superreview?(mscott)
(Assignee)

Comment 4

13 years ago
*** Bug 208578 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Attachment #154670 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 5

13 years ago
fixed on branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
(Reporter)

Updated

13 years ago
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.