209022 - renaming mail folders does not rename subfolders

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Stephan Bucher]

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
problem.

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

Comment 1

[David :Bienvenu]

I tried this on windows w/o a problem. Could it be OS/2-specific?

Comment 2

[Mike Kaply [:mkaply]]

This works fine for me as well.

Please try the current 1.4 branch build.

Comment 3

[David :Bienvenu]

Does this folder name have any non-ascii characters?

Comment 4

[T. Charles Yun]

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
<http://bugzilla.mozilla.org/show_bug.cgi?id=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.

Comment 5

[Daniel S. Reichenbach]

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.

Greetings,
Daniel

Comment 6

[Andrew Brady]

Attachment: Initial mail folder view showing all folders correctly

Comment 7

[Andrew Brady]

Attachment: mail folder view after restarting Mozilla is the same

Comment 8

[Andrew Brady]

Attachment: IMAP proto trace when Inbox is selected

Comment 9

[Andrew Brady]

Attachment: mail folder view after selecting Inbox - where are the subfolders

Comment 10

[Andrew Brady]

Attachment: Mail folder view after collapsing the view

Comment 11

[Andrew Brady]

Attachment: IMAP proto trace when folder view is expanded

Comment 12

[Andrew Brady]

Attachment: Finally back to the correctf view of the mail folders

Comment 13

[Andrew Brady]

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
  andy_imaptrace1.txt
  attach: andy_view3.gif
  % collapse server view
  attach: andy_view4.gif
  % expand server view
  attach: andy_imaptrace2.txt
  attach: andy_view5.gif

Cheers,

Andy

Comment 14

[Andrew Brady]

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
http://bugzilla.mozilla.org/show_bug.cgi?id=199155

Again, sorry.

Andy

Comment 15

[Mike Kaply [:mkaply]]

Not OS/2 specific

Comment 16

[David :Bienvenu]

ah, this is IMAP? You should try a 1.5b build, and let me know. I'll test it
with 1.5b as well.

Comment 17

[David :Bienvenu]

and are you using imap subscription (the default) or not?

Comment 18

[Sam Little]

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.

Comment 19

[Mike Kaply [:mkaply]]

What was the name of the folder you renamed?

What was the name of the subfolders?

How many subfolders did you have?

Comment 20

[Scott Davis]

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\
  stored
  stored.msf
  stored.sbd\
    subfolder
    subfolder.msf

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

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.

Comment 21

[David :Bienvenu]

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.

Comment 22

[David :Bienvenu]

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...

Comment 23

[David :Bienvenu]

Attachment: proposed fix

I went with the approach of using the db cache, and having the db cache close
the db if it's open...

Comment 24

[David :Bienvenu]

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.

Comment 25

[Mike Kaply [:mkaply]]

I like this fix a lot. Is it risky at all?

Comment 26

[David :Bienvenu]

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 27

[[e-mail]]

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)
  mailDBFactory->ForceFolderDBClosed(this);

Also the way you are using it in this fragment it looks as if mailDBFactory is
a service (do_GetService) rather than a component.

Comment 28

[David :Bienvenu]

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.

Comment 29

[David :Bienvenu]

marking fixed.

Comment 30

[Scott MacGregor]

*** Bug 230513 has been marked as a duplicate of this bug. ***

Comment 31

[Rolf Campbell]

*** Bug 199823 has been marked as a duplicate of this bug. ***

Comment 32

[David :Bienvenu]

fixed on m4 branch

Comment 33

[David :Bienvenu]

*** Bug 189134 has been marked as a duplicate of this bug. ***

Comment 34

[Mike Kaply [:mkaply]]

Comment on attachment 138638 [details] [diff] [review]
proposed fix

a=mkaply for 1.4.2

please mark fixed1.4.2 when checked in

Thanks