Closed Bug 541740 Opened 14 years ago Closed 14 years ago

Cannot delete folders permanently

Categories

(MailNews Core :: Backend, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: conrad, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.3; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

I have a sub folder under Local Folders called "Gungrips.net".  There are several sub folders to Gungrips.net, for example "01-2010" for Jan 2010.  In this folder, I file new orders for our products.  When the order is filled, I move it in a sub folder of "01-2010" such as "GG01707 J Jones order for wood".  I have run this using Thunderbird, Eudora and Sea Monkey.  In all three programs, after shutting down the e-mail program and opening it up again, some folders for customers filled orders reappear in the "01-2101" as well as where it should be in "GG01707 J Jones order for wood".  When I delete the unwanted folder, it does not go away from the trash until I shut down the e-mail and re-open it.  Now the nasty part happens - the folders reappear in the "01-2010" folder with some kind of number after them.  The trash is empty, but the unwanted folders are still there - EMPTY.  I believe this is in Core because it happens in several Mozilla type programs.  I should also add that the software picks the folders to do this at random.  It does not appear to be something I have done that make the folders different.

Reproducible: Always

Steps to Reproduce:
1.  Delete folders
2.  Empty Trash
3.  Close e-mail and re-open
4.  Observe unwanted folders in the "01-2010" folder
Actual Results:  
When the program opens the unwanted folders are in the "01-2010" folder as:

GG01701 J Jones order for wood grips w2a17491d

The original folder was named

GG01701 J Jones order for wood grips 

Please note the numbers added behind the folder name.  I haven't a clue what it is.



Expected Results:  
It should have deleted the folder to the trash and never had it reappear after restarting Thunderbird

Not much more I can add.  This always worked perfectly in Outlook Express until I "upgraded" to Windows 7 and had to find a new e-mail program.  Don't know where to look next so I hope you guys can figure something out.  The number of unwanted folders keep increasing and I do not know if it will ever stop.  I have to call it a "Normal bug" but I cannot find a work around and it could be a show stopper and force me back to Outlook - bummer
This should be somewhere in MailNews, but I have no idea where.

Nathan, I found you commenting on a recent UNCO bug in MailNews, I hope you can help triage this (or find someone who can).
Component: General → Backend
Product: Core → MailNews Core
QA Contact: general → backend
(In reply to comment #0)
> Actual Results:  
> When the program opens the unwanted folders are in the "01-2010" folder as:
> GG01701 J Jones order for wood grips w2a17491d

> The original folder was named
> GG01701 J Jones order for wood grips 

(Q1) Do you still have files under Trash.sbd directory?
If yes, keep bakup of "Local Folders" directory.
Original folder name may be held in .msf file in the backup.

(Q2) 2a17491d part is hashed value for illegal file name character or special character in folder name name.
Original folder name is probably:
     GG01701 J Jones order for wood grips w<special_char><others>
     hashed value of this folder name by Tb3 = 2a17491d
 ==> GG01701 J Jones order for wood grips w2a17491d
Check file names created by Tb3, please.
  Under Test of "Local Folders" : create X\ X? X# X. X<space> X~ etc.

(Q3) Open back up of GG ... 2a17491d.msf by text editor.
     Can you see string for orginal folder name in it?

Folder file name generation logic is slightly different among Mozilla/Sm/Tb(and Penelope) versions/builds.
Even if "file name for folder name with special character" was generated by older version of Tb, it's usually usable by newer version of Tb.
  - fnA is generated by older Tb from <folder name with special character>
  - fnA, fnA.msf as folder files.
  As <folder name with special character> is held in fnA.msf,
  or as relation between <folder name with special character> and fnA/fnA.msf
  is kept in folder cache data(panacea.dat etc.),
  newer Tb can use fnA, fnA.msf for <folder name with special character>
Upon delete of the folder(move to Trash) by newer Tb, original fnA /fnA.msf is copied under Trash.sbd.
After that, Tb tries to open <folder name with special character>.
  - fnB is generated by newer Tb from <folder name with special character>
  - fnB, fnB.msf as folder files
  - <folder name with special character> is held in .msf
If fnB != fnA, copied file of "fnA" is mail folder file for folder named "fnA" for newer Tb. Further, upon open/read of fnA.msf, newer Tb knows <folder name with special character> held in fnA.msf.
So next three sets can happen:
 a. <folder name with special character> : fnB / fnB.msf
 b. fnA                                  : fnA / fnA.msf    
 c: <folder name with special character> : fnA / fnA.msf 
    
This kind of mismatch can cause some problems when upgrade of Tb, and some bugs are really opened for such issues.
If shared use of mail folder files between Tb versions/builds and Penelope versions/builds, downgrade can easily happen, and similar problem can haaapen.
(In reply to comment #1)
> This should be somewhere in MailNews, but I have no idea where.

I doubt this goes in Backend, but I'm not sure where it does go, except maybe Database.


To add to what WADA said in comment #2, most of his questions involve digging around a bit in the profile directory (https://support.mozillamessaging.com/en-US/kb/Profiles#Where_is_my_profile_stored_); answers to those should help clear up a lot of this. If you need clarification on any of these, just ask.
Component: Backend → Database
QA Contact: backend → database
(In reply to comment #3)
> (In reply to comment #1)
> > This should be somewhere in MailNews, but I have no idea where.
> I doubt this goes in Backend, but I'm not sure where it does go, except maybe
> Database.
> To add to what WADA said in comment #2, most of his questions involve digging
> around a bit in the profile directory
> (https://support.mozillamessaging.com/en-US/kb/Profiles#Where_is_my_profile_stored_);
> answers to those should help clear up a lot of this. If you need clarification
> on any of these, just ask.
It looks like someone is looking at this issue and that's a good thing!  It was filling up my e-mail with trash folders and insisted on replacing them after I deleated them.  Finally, I could not deal with it and had to resort to using Windows live mail.  Good luck, hope someone figures it out.
Closing as INCOMPLETE, per comment #5 by bug opener.
To bug opener, please re-open this bug, if you'll find solid/crisp/minimum procedure to reproduce your problem, with attaching sufficient data for diagnosis.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Backend is more appropriate than database, which has to do with .msf files and gloda.

Were there any special chars in your folder name, or was it an issue with duplicate folder names?
Component: Database → Backend
QA Contact: database → backend
David,  I'm sorry to abandon this at this point, but I have a business to run and cannot spend the time on it.  For what it's worth, I made sure all the folders in the e-mail had unique names, no duplicates.  I tried really hard to use several of the e-mail programs.  I suspect they would be fine for very small e-mail accounts, but I keep a lot of business contacts and orders in the e-mail account.  Wish I had the time to go back into programming and work with things like this, but no time for fun any longer.
Status: RESOLVED → VERIFIED
Resolution: INCOMPLETE → WONTFIX
You need to log in before you can comment on or make changes to this bug.