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

renaming mail folders does not rename subfolders

RESOLVED FIXED

Status

MailNews Core
Backend
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: Stephan Bucher, Assigned: Bienvenu)

Tracking

({fixed1.4.2})

Trunk
x86
All
fixed1.4.2

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments)

(Reporter)

Description

15 years ago
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
(Assignee)

Comment 1

15 years ago
I tried this on windows w/o a problem. Could it be OS/2-specific?
Status: UNCONFIRMED → NEW
Component: Mail Database → Mail Back End
Ever confirmed: true

Comment 2

15 years ago
This works fine for me as well.

Please try the current 1.4 branch build.
(Assignee)

Comment 3

15 years ago
Does this folder name have any non-ascii characters?

Comment 4

14 years ago
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

14 years ago
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

14 years ago
Created attachment 129715 [details]
Initial mail folder view showing all folders correctly

Comment 7

14 years ago
Created attachment 129716 [details]
mail folder view after restarting Mozilla is the same

Comment 8

14 years ago
Created attachment 129718 [details]
IMAP proto trace when Inbox is selected

Comment 9

14 years ago
Created attachment 129719 [details]
mail folder view after selecting Inbox - where are the subfolders

Comment 10

14 years ago
Created attachment 129720 [details]
Mail folder view after collapsing the view

Comment 11

14 years ago
Created attachment 129721 [details]
IMAP proto trace when folder view is expanded

Comment 12

14 years ago
Created attachment 129722 [details]
Finally back to the correctf view of the mail folders

Comment 13

14 years ago
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

14 years ago
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

14 years ago
Not OS/2 specific
OS: other → All
(Assignee)

Comment 16

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

Comment 17

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

Comment 18

14 years ago
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

14 years ago
What was the name of the folder you renamed?

What was the name of the subfolders?

How many subfolders did you have?

Comment 20

14 years ago
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.
(Assignee)

Comment 21

14 years ago
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.
(Assignee)

Comment 22

14 years ago
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...
(Assignee)

Comment 23

14 years ago
Created attachment 138638 [details] [diff] [review]
proposed fix

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

Updated

14 years ago
Attachment #138638 - Flags: superreview?(mscott)

Updated

14 years ago
Attachment #138638 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 24

14 years ago
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

14 years ago
I like this fix a lot. Is it risky at all?
(Assignee)

Comment 26

14 years ago
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

14 years ago
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.
(Assignee)

Comment 28

14 years ago
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.
(Assignee)

Comment 29

14 years ago
marking fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 30

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

Comment 31

14 years ago
*** Bug 199823 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Blocks: 230700
(Assignee)

Comment 32

14 years ago
fixed on m4 branch
(Assignee)

Comment 33

14 years ago
*** Bug 189134 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Attachment #138638 - Flags: approval1.4.2?

Comment 34

14 years ago
Comment on attachment 138638 [details] [diff] [review]
proposed fix

a=mkaply for 1.4.2

please mark fixed1.4.2 when checked in

Thanks
Attachment #138638 - Flags: approval1.4.2? → approval1.4.2+
(Assignee)

Updated

14 years ago
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.