Closed Bug 209022 Opened 21 years ago Closed 21 years ago

renaming mail folders does not rename subfolders

Categories

(MailNews Core :: Backend, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stephan.bucher, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.4.2)

Attachments

(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 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
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
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 <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.
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
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
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
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\ 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.
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 fix (deleted) — Splinter 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) 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.
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.
Status: NEW → RESOLVED
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 Thanks
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.

Attachment

General

Creator:
Created:
Updated:
Size: