Closed Bug 209022 Opened 21 years ago Closed 21 years ago

renaming mail folders does not rename subfolders


(MailNews Core :: Backend, defect)

Not set


(Not tracked)



(Reporter: stephan.bucher, Assigned: Bienvenu)



(Keywords: fixed1.4.2)


(8 files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4) Gecko/20030529

When a mail folder is renamed, the *.sbd are not being renamed and do not show
up in the liost anymore. Renaming *.sbd manually with a file manager solves the

Reproducible: Always

Steps to Reproduce:
1. rename mail folder containing subfolders
2. close mozilla
3. run mozilla again

Actual Results:  
the subfolders of the renamed mail folder are not visible anymore

Expected Results:  
renamed *.sbd files according to renaming action of main folder
I tried this on windows w/o a problem. Could it be OS/2-specific?
Component: Mail Database → Mail Back End
Ever confirmed: true
This works fine for me as well.

Please try the current 1.4 branch build.
Does this folder name have any non-ascii characters?
Mozilla 1.4b
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

I have run into this problem as well.  The symptoms seem related to bug #199823

In my scenario, when I re-named the folder, subfolders were visible in the
folder pane, but you could see any messages.  If you renamed the folder back to
its orig name, everything seems to return to normal/work fine.  

I recall that there was also a problem somewhere if you used a leading space for
the folder name.

I have tried the same thing in our network on several Windows XP and 2k boxes. 
Whenever a folder with subfolders is renamed, the subfolders won't be moved in 
the filesystem and after the next restart, they will not be available anymore 
until moving them manually into the new folder.

I have a similar problem which I think is related.
I am using Courier IMAP with moz release 1.4.

I am not sure if my problem is complicated by the way I
am accessing the Courier. Courier places all folders
as subfolders of the INBOX, so by default they appear
as sub folders when the Mozilla IMAP config is default. I
have changed the config such that the Server Directory is
"INBOX.", the namespaces are blank and the server cannot
reset them. This results in the correct view that I want to
have of the folders. The only problem that occurs is that
the first connection to Courier makes an IMAP request
(not the forward slash):

  list "" "INBOX./%"

which result in the correct subfolder list being
returned. When I collapse and expand the server view,
Mozilla makes the IMAP request (no forward slash
in this one):

  list "" "INBOX.%"

which results in the list of children. This is
reproducable and the steps required to reproduce
are (refer to previous attachments):

  attach: andy_view1.gif
  % quit mozilla mail
  % start mozilla mail
  attach: andy_view2.gif
  % click Inbox
  attach: andy_view3.gif
  % collapse server view
  attach: andy_view4.gif
  % expand server view
  attach: andy_imaptrace2.txt
  attach: andy_view5.gif


Sorry. I have just added comments and attachments to the wrong bug.
Stupid me.

Please ignore comments/attachments 6 through 13 which are not part of
this bug but were supposed to be on bug

Again, sorry.

Not OS/2 specific
OS: other → All
ah, this is IMAP? You should try a 1.5b build, and let me know. I'll test it
with 1.5b as well.
and are you using imap subscription (the default) or not?
I've been bitten by this bug today as well (Mozilla/5.0 (OS/2; U; Warp 4.5;
en-US; rv:1.5b) Gecko/20030825). Not IMAP-related; this was in "Local Folders"
tree. Had to manually rename the .sbd directory to match folder name.
What was the name of the folder you renamed?

What was the name of the subfolders?

How many subfolders did you have?
I ran into this bug in Thunderbird 0.4 on Windows XP. In the following scenario,
Thunderbird fails to rename the directory.

Original mail structure on disk:
Local Folders\

mail structure on disk after renaming the folder 'stored' to 'stored2':
Local Folders\

Since the subfolder is not renamed, the files in the subdirectory are not
recognized. Manually renaming stored.sbd to stored2.sbd fixes the problem.

I think I also ran across this bug (or something similar anyway) on IMAP. My
folder structure was seriously messed up when I tried to rename a folder with
many subfolders. I had to manually unsubscribe the new folder name and
re-subscribe the old folder name and everything started working again.
OK, the problem occurs if one of the sub-folders' .msf files is held open for
some reason, which makes the OS fail in moving the parent directory. I thought
there was code that ran through forcing them closed - I'll go look.
there is code that forces all the db's for the sub-folders closed. However, it
doesn't work if the mDatabase member on the folder object isn't set *and*
someone else is holding a reference to the nsIMsgDatabase.  Most of the time,
it's js holding onto the db, because garbage collection hasn't run. One solution
would be for the code that forces all the db's closed to first open the db's, so
that they can then be force closed. Another possibility is to take advantage of
the fact that the msgdb component keeps a list of open db's and force them
closed from the db cache. Unfortunately, there's no interface to do that. I can
clean up the js that's holding onto the db for a quick fix, but someone will
always come along and write js that breaks us...
Attached patch proposed fixSplinter Review
I went with the approach of using the db cache, and having the db cache close
the db if it's open...
Attachment #138638 - Flags: superreview?(mscott)
Attachment #138638 - Flags: superreview?(mscott) → superreview+
fix checked in. I believe this was only a problem if you've accessed the
children folder before you try to rename the parent folder.
I like this fix a lot. Is it risky at all?
it's pretty safe. The one risk is that someone is holding onto the db and not
listening for the notification that the db has been closed, and then tries to
use the db pointer downstream. But we had that risk before...
Comment on attachment 138638 [details] [diff] [review]
proposed fix

>+      nsCOMPtr<nsIMsgDatabase> mailDBFactory;
>+      nsresult rv = nsComponentManager::CreateInstance(kCMailDB, nsnull, NS_GET_IID(nsIMsgDatabase), (void **) getter_AddRefs(mailDBFactory));
>+      if (NS_SUCCEEDED(rv) && mailDBFactory)
>+        mailDBFactory->ForceFolderDBClosed(this);
Nit: Can't you say something like this:
nsCOMPtr<nsIMsgDatabase> mailDBFactory = do_CreateInstance(kCMailDB);
if (mailDBFactory)

Also the way you are using it in this fragment it looks as if mailDBFactory is
a service (do_GetService) rather than a component.
that's pretty much the tip of the iceberg. This db code was written in the very
early mozilla days and has never been updated. It needs to use contract id's,
for one thing. And the whole db factory bootstrapping thing, where some of the
methods should really be part of a service, should be fixed as well.
marking fixed.
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 230513 has been marked as a duplicate of this bug. ***
*** Bug 199823 has been marked as a duplicate of this bug. ***
Blocks: 230700
fixed on m4 branch
*** Bug 189134 has been marked as a duplicate of this bug. ***
Attachment #138638 - Flags: approval1.4.2?
Comment on attachment 138638 [details] [diff] [review]
proposed fix

a=mkaply for 1.4.2

please mark fixed1.4.2 when checked in

Attachment #138638 - Flags: approval1.4.2? → approval1.4.2+
Keywords: fixed1.4.2
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.