Closed Bug 203071 Opened 22 years ago Closed 17 years ago

copying subfolder of imap account to other acount only works once per starting mozilla

Categories

(MailNews Core :: Backend, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: thomas.gantner, Assigned: Bienvenu)

Details

(Whiteboard: closeme 2008-08-15)

User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3) Gecko/20030312 I tried to copy (by individual drag-n-drop) several subfolders from one of my imap accounts to my local folders. The first subfolder copied flawlessly, but dragging subsequent folders had no effect. After restarting mozilla I was again only able to move exactly one more subfolder. Reproducible: Always Steps to Reproduce: 1. Start MailNews 2. Drag a subfolder of an imap account and drop onto "Local Folders", wait for completion of copying 3. Drag another imap subfolder to "Local Folders" Actual Results: Step 3 has no effect, even the mozilla-icon on the righthand side of the mail toolbar shows now activity (which it does during step 2) Expected Results: Copy the folder as in step 2 I have also installed - enigmail/enigmime 7.4.0 - calendar 2003-03-31 It's not that important. I need this functionality to burn my messages (neatly sorted into almost 100 folders) onto cd-rom. I only have access to the mail server via imap, and since there is no "export as mbox" I like to copy the files from my profile.
taking
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have the same problem in Windows 2000, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507. I can always copy one subfolder, sometimes two or three to the same destination, before having to restart. But sometimes copying seems to restart later spontaneously. With some trial and error I have got a good idea what is happening. It seems like there is a daemon or something which can stop and fail to restart even though there is a queue of jobs for it to do. I have discovered that it can stop in the following circumstances - but this is not an exhaustive list: 1) Try to copy an IMAP folder before all its headers have been fetched; 2) Copy an empty IMAP folder; 3) Try to copy to a location where there is already a folder with the same name (error message appears, copying stops and doesn't restart on hitting OK); 4) Sometimes simply when there is no more copying to do - so it works better to request a new copy before the previous one has finished. The following strategies can often get copying to restart: 1) Copy a folder to a different destination - it has to be one which has not been a destination before in this session; 2) Send a folder to trash - maybe if this is a new destination. Copying between local folders works independetly. It looks to me as if this bug should be fixed rather easily by giving the daemon a wake-up call every time a new copy is requested, even if to a folder which has already been a copy destination.
I just tried a few tests, and it worked fine. I copied a parent folder with 6 sub folders, and then a parent folder (empty) with one sub-folder, and everything was copied successfully. Do your folders have lots of messages? I believe that the urls are getting stalled (just clicking get messages on the source server should get things going again, if that's the case) but I can't reproduce it at the moment.
I tried a test where I copied folders with lots of messages in them - the copy looks a little like it's stalled (i.e., there's no ui feedback) but the copy is still going on - I can tell by the hard drive noise. You can also tell by turning on the size column in the folder pane and clicking on the folders occasionally and watching the size change, or using the file system explorer to look at the size of the mailbox. I doubt that's what's happening to you, but I thought I'd mention it.
Product: MailNews → Core
Hi, I can reproduce the bug in Thunderbird RC1 and RC2 (in a variation also in Mozilla 1.7.12 - see below) in Win2k, Imap-server is Cyrus. What I do: 1. Start Thunderbird 2. create a local folder "test" 3. drag & drop an imap-folder "foo" containing 2 subfolders (each containing ~10 mails) into test and check the filesystem: everything as expected 5. rename "foo" to "foo 1", filesystem-folder is renamed 6. drag & drop imap's "foo" again into "test" - nothing happens After a restart, it works again. By the way: Copying Folders including subfolders from local to Imap also doesn't work properly. Sometimes the subolders are copied, in the last 3 attempts only the "parent" folder gets copied. A similiar problem appears in Mozilla 1.7.12 but it's more weird there and I didn't anaylze it in detail till now. Any more information that I should/could provide?
This old bug still seems to be around. We are migrating to tbird version 2.0.0.14 (20080421) and switching IMAP servers at the same time. To do this in a staged manner users are being setup with accounts on both servers and then cleaning/reorganizing/moving folder from one server to the other. While it takes more than one folder copy eventually dragging a folder from one IMAP server to another results in nothing (no even an error: no activity).
Daryle, I would think your issue is a different bug - this bug is about folder move working only once per startup. Please get an imap log http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html and then hook up on a different bug.
QA Contact: esther → backend
FYIW, Franz's email is dead
Peter or any one still see this problem? WFM current trunk reporter "[doesn't] use Mozilla/Thunderbird any more"
Whiteboard: closeme 2008-08-15
I do use Thunderbird but rarely imap accounts, so I wouldn't see this problem even if it is still there.
Product: Core → MailNews Core
RESO WFM per comment 9 + 10. If you feel this change was made in error, please respond to this bug with your reason why.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.