Closed Bug 97943 Opened 18 years ago Closed 6 years ago

Sent Folder in "root" recreated even if Sent Folder moved

Categories

(MailNews Core :: Movemail, enhancement)

Product:
MailNews Core
Component:
Movemail
Type:
enhancement
Priority:
Not set

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 24.0

People

(Reporter: bugzilla, Assigned: aceman)

References

Details

Attachments

(1 file, 1 obsolete file)

patch v2
3.34 KB, patch
jcranmer
: review+
Details | Diff | Splinter Review 
Hi

Since I dont use the Sent, Drafts and Templates - Folders very often and to save
space I created a general Folder "Stuff" where I moved all those three folders
in and also looked that everything is set correctly in the preferences. The
Mailer uses those folders correctly, BUT those three folders are re-created
every time I restart Mozilla in the root, no matter how often I delete them.

What should be different:
Mozilla should see, that those folders are moved and that they already exist so
that it doesn't have to recreate them in the main folder of this account.

I didn't find another bug which was about exact this phenomenon, though ther are
a lot of close hits. (Bug 51906 (Recreation of Sent Folder), Bug 95709 (Problems
with changing of Sent Folder)).
Maybe it's a related problem, otherwise please make a new one out of it: I tried
to move all my Messages in my (moved) sent folder to the re-created one to do
some testing. There are 1968 Messages in it. I selected all, moved them to the
main Sent Folder, but only 744 of them arrived there. Even when I tried to move
the others, there remained those 744 and none of the new ones were added......

Matt
Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
WORKS FOR ME 

Windows 2000
./nightly/latest-1.0.0/
Build 2002041617

Reporter: This bug is 8 months old. Have you tried with a newer build?

Can someone (reporter?) marked this as fixed or works for me?
Hi

Still doesn't work for me!
I do the following:
Add a Folder named "Stuff" to my main mail.
Add a Folder named "Sent" to that folder "Stuff".

Go to mail preferences, choose where sent mails should be stored =>  <my 
account>/Stuff/Sent

Kill the Sent Folder in the root of this account.
Empty trash (doesn't matter)
quit and restart Mozilla.
--> The Sent folder is there again!

Using 2002041617 on Win2k...

Matti
BUT! does the mail go to <my account>/Stuff/Sent ???

The creation of the default folder isn't a bug in my opinion. Asking that it's
creation be supresses is a feature request.

Reporter: If the mail is correctly transfered to <my account>/Stuff/Sent, would
you care to change SEVERITY to enhancement? I.E. feature request?
Yes, the mail gets delivered into the right folder.
Of course this bug isn't CRITICAL and could be seen as a feature request, but I 
still think this is a BUG which needs to be fixed.. since you HAVE the 
functionality to change the default folder, this recreation should be avoided 
too.. I guess this is hardcoded somewhere and not dependent on what's selected 
in the preferences?
I'm not a mozilla-programmer but I dont think that would be THAT a big thing to 
have the folder-to-be-recreated as a parameter depending on the settings...?

Matti
Matti, still exists on 1.0RC1 ? If not, set the but to "worksforme"
Yes, still the same problem...

Aren't you able to reproduce it?
Please tell me what I might do to track this one down if you cant reproduce it..

Matti
Using builds 20020520 and earlier.
Matti is correct in stating the Sent, Drafts & Template folders are recreated
each time you launch the app if your POP and/or Local Folders don't have one
even it they are not designated as folders for for copies of Sent messages,
Draft messages and Templates.  Since this recreation is by design, this bug is a
feature request to allow the user to stop the recreation of these folders if
they don't exist and are not needed by the user.Changing severity from normal to
enhancement and status as New
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
As the reporter of this bug I cannot quite agree with all you said. I dont want 
to DELETE them permanently or something like that, I want to MOVE them because I 
rarely use them and I dont want them to be on top of the structure where I 
usually have tons of own private folders...
So in my case I then have those folders TWICE. Once in 'root' and once in my 
folder where I want them to be (because I can collapse it and it will only use 
the height of ONE item.

So I think this IS a Bug and not only a feature request?

Matti
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 10 years ago
Resolution: --- → EXPIRED
Still an issue for Movemail, POP/IMAP seems to work.
Status: RESOLVED → REOPENED
Component: MailNews: Message Display → MailNews: General
Ever confirmed: true
QA Contact: message-display → mail
Resolution: EXPIRED → ---
Status: REOPENED → NEW
Component: MailNews: General → Movemail
Product: SeaMonkey → MailNews Core
QA Contact: mail → movemail
Attached patch patch (obsolete) — — Splinter Review 
This could do it. The original code even create the folder files directly on disk, so they were picked up only at next TB start. So if they were missing in the current session, they would still not be available if needed. Strange. This is also done in RSS server type.
So now using CreateLocalFolder the folders are seen immediately.

I am not sure why POP3 behaves differently and does not need this patch. But maybe we could still use this also in other server types.

(I wonder why CreateDefaultMailboxes is separate from SetFlagsOnDefaultMailboxes, with this patch we could set the special flags immediately on the created folders... Could be for another bug.)
Assignee: nobody → acelists
Status: NEW → ASSIGNED
Attachment #761819 - Flags: review?(neil)
Attachment #761819 - Flags: review?(Pidgeot18)
(In reply to :aceman from comment #20)
> I am not sure why POP3 behaves differently and does not need this patch. But
> maybe we could still use this also in other server types.

These days, I think the Sent folder is set up with appropriate flags when you first try to use it, and somewhere along the line people removed the CreateDefaultMailboxes for POP. I don't know off the top of my head, but I think the critical stuff (Sent/Trash) are set up when you first try to use them, so there shouldn't be a need to do that for CreateDefaultMailboxes for Movemail either.
CreateDefaultMailboxes for POP still exists, just does not create the other folders like Drafs/Templates/Sent :
http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3IncomingServer.cpp#443

Do you mean to also strip the function to only do the Inbox+Trash for movemail ?
Flags: needinfo?(Pidgeot18)
Comment on attachment 761819 [details] [diff] [review]
patch

I don't think changing CreateLocalFolder is a good idea as you can redirect special folders and end up with multiple special folders in one account.
Attachment #761819 - Flags: review?(neil) → review-
(In reply to neil@parkwaycc.co.uk from comment #23)
> I don't think changing CreateLocalFolder is a good idea as you can redirect
> special folders and end up with multiple special folders in one account.

Yes you can have more in one account. And the new CreateLocalFolder will actually see them and not create another ones. Without the patch it created them under root folder without asking. So I do not understand what is worse with the patch.
(In reply to :aceman from comment #22)
> CreateDefaultMailboxes for POP still exists, just does not create the other
> folders like Drafs/Templates/Sent :
> http://mxr.mozilla.org/comm-central/source/mailnews/local/src/
> nsPop3IncomingServer.cpp#443
> 
> Do you mean to also strip the function to only do the Inbox+Trash for
> movemail ?

Yes
Flags: needinfo?(Pidgeot18)
Attachment #761819 - Flags: review?(Pidgeot18)
(In reply to Joshua Cranmer [:jcranmer] from comment #25)
> (In reply to :aceman from comment #22)
> > CreateDefaultMailboxes for POP still exists, just does not create the other
> > folders like Drafs/Templates/Sent :
> > http://mxr.mozilla.org/comm-central/source/mailnews/local/src/
> > nsPop3IncomingServer.cpp#443
> > 
> > Do you mean to also strip the function to only do the Inbox+Trash for
> > movemail ?
> 
> Yes

Correction: you might not even need Trash, but I'd recommend checking first.
Attached patch patch v2 — — Splinter Review 
Thanks. I tested that Drafts and Templates are created automatically. Unsent Messages uses the global unsent folder (may be in other account). Trash is needed to be created here as otherwise Delete message throws.
Attachment #761819 - Attachment is obsolete: true
Attachment #766333 - Flags: review?(Pidgeot18)
Attachment #766333 - Flags: review?(Pidgeot18) → review+
Keywords: checkin-needed
OS: Windows 2000 → All
Hardware: x86 → All
Blocks: 886112
https://hg.mozilla.org/comm-central/rev/00e582fb8c72
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0
(In reply to Joshua Cranmer from comment #21)
> (In reply to aceman from comment #20)
> > I am not sure why POP3 behaves differently and does not need this patch. But
> > maybe we could still use this also in other server types.
> 
> These days, I think the Sent folder is set up with appropriate flags when
> you first try to use it, and somewhere along the line people removed the
> CreateDefaultMailboxes for POP. I don't know off the top of my head, but I
> think the critical stuff (Sent/Trash) are set up when you first try to use
> them, so there shouldn't be a need to do that for CreateDefaultMailboxes for
> Movemail either.

Ah yes, this briefly confused me when I skimmed the patch, but of course the Sent, Drafts and Templates are properties of the identity, not the server, so they don't belong here. (Fortunately for me this got dealt with admirably anyway.)
You need to log in before you can comment on or make changes to this bug.