Closed
Bug 209022
Opened 21 years ago
Closed 21 years ago
renaming mail folders does not rename subfolders
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: stephan.bucher, Assigned: Bienvenu)
References
Details
(Keywords: fixed1.4.2)
Attachments
(8 files)
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
mscott
:
superreview+
mkaply
:
approval1.4.2+
|
Details | Diff | Splinter Review |
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•21 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•21 years ago
|
||
This works fine for me as well.
Please try the current 1.4 branch build.
Assignee | ||
Comment 3•21 years ago
|
||
Does this folder name have any non-ascii characters?
Comment 4•21 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•21 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•21 years ago
|
||
Comment 7•21 years ago
|
||
Comment 8•21 years ago
|
||
Comment 9•21 years ago
|
||
Comment 10•21 years ago
|
||
Comment 11•21 years ago
|
||
Comment 12•21 years ago
|
||
Comment 13•21 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•21 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
Assignee | ||
Comment 16•21 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•21 years ago
|
||
and are you using imap subscription (the default) or not?
Comment 18•21 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•21 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•21 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•21 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•21 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•21 years ago
|
||
I went with the approach of using the db cache, and having the db cache close
the db if it's open...
Assignee | ||
Updated•21 years ago
|
Attachment #138638 -
Flags: superreview?(mscott)
Updated•21 years ago
|
Attachment #138638 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 24•21 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•21 years ago
|
||
I like this fix a lot. Is it risky at all?
Assignee | ||
Comment 26•21 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•21 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•21 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•21 years ago
|
||
marking fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 30•21 years ago
|
||
*** Bug 230513 has been marked as a duplicate of this bug. ***
Comment 31•21 years ago
|
||
*** Bug 199823 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 32•21 years ago
|
||
fixed on m4 branch
Assignee | ||
Comment 33•21 years ago
|
||
*** Bug 189134 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•21 years ago
|
Attachment #138638 -
Flags: approval1.4.2?
Comment 34•21 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•21 years ago
|
Keywords: fixed1.4.2
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•