User Agent: Mozilla/5.0 (Windows NT 6.1; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

Running TB 102.1.1, POP3, Norton Security AV.

(i) Download message(s) to be filtered and moved to a destination folder.
(ii) REPAIR the Inbox.

(It might matter if the download -- and the subsequent redirective move -- is the FIRST operation since launch of TB. This mattered in the past regarding certain DELETEs and MOVEs.)

Actual results:

(i) Message(s) move correctly to the destination folder. There is no sign of them in the Inbox.
(ii) The message(s) re-appear in the Inbox.

I have full copies of the Headers if needed, but suffice to say the only difference is a slight re-arrangement of three "Mozilla" lines in the filtered version which indicate slightly different processing of each by TB.

INBOX:
From - Sun Aug 7 09:14:07 2022
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys: test
X-Account-Key: account4
X-UIDL: UID19618-1431996386
Return-path: <idr3SRKf0mIkaBlQUf2hHTDNQkBkdwDp1ziW@bounce.researchgate.net>

DESTINATION:
From - Sun Aug 7 09:14:07 2022
X-Account-Key: account4
X-UIDL: UID19618-1431996386
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: <idr3SRKf0mIkaBlQUf2hHTDNQkBkdwDp1ziW@bounce.researchgate.net>

Expected results:

(i) Correctly moved to destination folder.
(ii) Message SHOULD NOT be "recovered" and reincarnated in Inbox.

I don't think this is a Filter issue per se, as the filtering itself works. Symptom is more like an the original transient error where items that had been DELETE'd or MOVE'd (a form of delete) which mangles the Inbox until REPAIR is run.

Additional comments from my notes:

This bug presented itself in the past too -- for sure under TB 102.1.0 and I think possibly earlier 102's -- but I didn't understand what I was seeing at the time. It seemed there was a duplicate download, as opposed to a reincarnation of something already there and deleted.

A duplicate would have been filtered again -- and yes, that had indeed happened with some dups! They not only downloaded again and got filtered to the destination again too, but the dups also "re-appeared" in the Inbox following a REPAIR. But sInce I was expecting dups, I saw dups! I just couldn't explain why a dup would end up in the Inbox instead of the destination. In fact, there was the dup in the destination (two identical copies were present there) and I was seeing its reincarnation in the Inbox.

So I'm proposing that the underlying issue is INCOMPLETE DELETION of filtered files from the Inbox, which then become reincarnated there because of their incomplete erasure (deletion) during (or following) the filtered move to the destination.

(FYI, consecutive content in my recent filter log has two entries showing application of a MOVE-type filter to two downloads -- which later became reincarnation material -- separated by several applications of a simple tagging filter which all worked as intended with no additional issues.)

(ii) REPAIR the Inbox.

Yes, anything you move from pop3 source folder to another folder comes back after a repair of source, even if you compact before the repair. Verified on a pop source folder. It didn't do it for an imap source folder.

I'm confirming this on daily 105.0a1 updated and built yesterday.

Note: Probably mbox specific since I don't see this on my Local Folders stored as maildir.
Also, movement of messages by filtering is not a factor. The bug occurs even if moved via menus or drag-drop.

I tried to reproduce this but couldn't (on daily). There must be some missing piece to this puzzle. Tried moving to other folders on the pop3 account, and moving to a folder under Local Folders. Then folder properties | Repair folder (for the inbox).

It failed for me yesterday. I'll try again in a while.
Your pop3 account is mbox, right?

Yes, Gene -- MBOX. One big file per account containing all of its emails.

Mine too is mbox.

Magnus, the missing piece might be that perhaps it occurs only when the filter's MOVE (move-by-filter) is the first thing that happens after launching TB. In one of my original bug postings for 102.0, there was a combination of a seemingly benign display issue and certain corruption with DELETE (or MOVE, which deletes), where the issue happened only when DELETE (or MOVE) was the very first thing that happened after launching TB. (Looks to me like your MOVEs etc were a consecutive series of steps, rather than any one being a single step immediately after launching TB.)

In THIS bug, I know I did a GET MESSAGE for a specific account right after launch, and it downloaded a message that triggered a MOVE by a filter. Nothing special so far. I then wanted to do a COMPACT, so I ran REPAIR -- and the filtered message appeared in the Inbox, along with a similar message from the same account and processed by the same filter. I'm pretty sure downloading this other message (and its filtering) was also the first thing done on the previous launch (which would have been the first run of TB 102.1.1 following its installation) -- happened to be the same account, and by sheer coincidence happened to be the same type of message!

So the same circumstance (two first-action downloads with filtered MOVEs) seems to have reincarnated those two messages. And as I said, I saw similar reincarnations in TB 102.1.0 for sure (as I was doing similar things), but thought they were just pesky duplicate downloads. I didn't realize until now that they were the remnants of MOVE'd messages.

FYI, my structure is ONE Inbox under Local Folders, with all accounts coming into it, and with all other folders (with subs) also under Local Folders. Specific filters exist for various accounts. (And I'm using MBOX format...)

Edit: "...seems to have reincarnated those two messages."
I meant: "...seems to have led to the reincarnation of those two messages."

I guess I was wrong. Just manually MOVEing the message doesn't trigger the bug.
But with a simple filter to move the message on subject containing "moveme" the messages comes back into Inbox after repair.

Also, seems to happen any time the filter does the move after new mail is received, not just on startup. But messages run by manually running the filter don't come back on repair.

I then wanted to do a COMPACT, so I ran REPAIR

Just a question: If you wanted to compact, why not just run the right-click item "Compact"?
(Of course, repair or compact shouldn't cause a moved message to come back.)

BECAUSE... In the initial TB 102.0 release, the first thing I fell over was corrupted messages when COMPACT was run without running REPAIR first. (Don't know why -- and not every time either. Just seemed that the folder had to be in good shape before attempting to compact it.) And the reason THAT happened is because TB 102 installation set COMPACT to be automatic (which I never wanted) -- without telling us users, and so COMPACT just ran, uninvited. Then to add insult to injury, the COMPACT process itself was flawed and often got triggered prematurely and/or repetitively, so it ran when it felt like it. Given that many of the issues I've seen are unpredictable and transient (and sometimes random, it seems), I just want to be cautious and not believe something is working right this time because it didn't fail last time.

Also, seems to happen any time the filter does the move after new mail is received, not just on startup.

This very well could be. I just know that the episodes I saw were both after a filter-generated MOVE, and they both happened immediately after launch, and -- because I often do a series of things the same way -- I saw it a few times previously too (so before 102.1.1) without recognizing it for what it is. Whereas I can't say I've seen it on "non-first-event" filtered MOVEs even though there have been several such MOVEs. But regardless, if you also saw it happen -- even on a non-first-event -- then it's a bug, and I'm (maybe) not crazy. :)

...messages run by manually running the filter don't come back on repair.

I speculated in the STR (and elaborated in my Comment 1) that there is something weird or incomplete about the deletion process performed by the filtered MOVE. Might there be a slightly different flow taken by a manual filter on existing messages vs the automatic filtering of something inbound? Something initialized differently, or not at all? Or a different flag or semaphore setting? (Just thinking out loud...)

Gene, in your Comment 2 and Comment 9:

Anything you move from pop3 source folder to another folder comes back after a repair of source...
I guess I was wrong. Just manually MOVEing the message doesn't trigger the bug...

That's right, now. But originally it did. Any manual deletion (DELETE or MOVE) left something that tripped up COMPACT if you didn't run REPAIR first -- such that some deleted messages re-appeared and usually nearby messages got corrupted in the deal. You'd get subjects with incorrect content, or raw content (text, html, whatever), or a full & proper message with a ton of something else (usually benign but not guaranteed) tacked on the end.

And I don't know for sure that this aspect has actually been fixed -- I don't recall anything specific being said in any Release Notes -- and I haven't been brave enough to try it, since the TB 102 machine isn't totally mine.

And I don't know for sure that this aspect has actually been fixed -- I don't recall anything specific being said in any Release Notes -- and I haven't been brave enough to try it, since the TB 102 machine isn't totally mine.

I don't know what the release notes say but this bug addressed a lot of the corruption issues you describe: bug 1777454. The patch is in the latest 102.

Thanks, Gene. I looked it over (and a few links) but saw nothing explicitly saying the corruption issues have been totally fixed.

FYI, I'm currently running TB 102.1.1 Release, and apparently 102.1.2 is imminent but hasn't yet come up under HELP, ABOUT for upgrading. By "latest 102", do you mean either of these? Or something in beta? (I usually prefer to stick to the formal releases...)

I'm referring to that latest official 102 release, whatever that is. One other thing, if I remember right, the problems are often triggered by the setting to enable anti-virus quarantine setting in TB. You haven't mentioned if you have than enabled.

I'm running Norton Security AV, and YES, I have the setting to quarantine ENABLED. I do remember early thoughts that this could cause problems, but I understood from various subsequent comments that Norton had been vindicated in this issue.

As for TB 102.1.2, it is available now and I will be installing it shortly...

Wayne, what do you need from me? (Did you maybe intend the needinfo for bugzilla2007@duellmann24.net since they were just added as CC?)

BTW, so far I haven't seen any moved or deleted messages reappear in recent versions of TB 102. I've run REPAIR & COMPACT only a few times, but that's usually been enough to catch it. (I installed TB 102.2.1 on Sept 1st but haven't run REPAIR with it.)

So now running TB 102.2.2, just released today...

I ran a REPAIR and COMPACT on Inbox. First thing that happened was that the UNREAD count jumped from zero to 22. (Unfortunately I'm not sure about TOTAL MESSAGES count, but I don't think it changed.) In any case, all 22 messages had recently been filtered and MOVE'd on arrival by those filters to one of two folders. (Filters are simple: If this, move there, stop.)

There had been several DELETEs and manual MOVEs over the same period -- none of these came back.

There have been no signs of corruption (where REPAIR and COMPACT cause deleted messages to reincarnate and scramble a few live ones) in recent releases.

Last night (07-Sept-2022), I reconfigured GET MESSAGES to include several of my usual accounts. Then I clicked the GM button several times over the course of the evening, leaving the Laptop unattended in between, and I also did manual polls & fetches periodically -- no issues to that point. This morning (08-Sept-2022), at some point the UNREAD counter jumped from zero to 100 (1 real, 99 duplicate downloads) -- see Bug 1778037).

I deleted the duplicates and ran REPAIR on Inbox, only to find 22 reincarnated messages had re-appeared yet again -- and all had been redirected (moved) by a filter.

So I still have the issues of:
(i) duplicate messages coming down -- sooner or later -- if the GET MESSAGES button is clicked (Bug 1778037), and
(ii) REPAIR causing filtered messages to re-appear in the Inbox (THIS bug).

Are you using any deferred inboxes? Or do all pop accounts deliver to their own account inbox?

I'm running only POP3 accounts, and all share one global inbox. (Is that what you mean by "deferred"?)

Environment details: TB 102.2.2 32-bit (newly installed official release), running on Windows 7/Pro +SP1 (32-bit), with Norton AV scanning all inbound emails.

Configuration details: All accounts (except one) normally linked to GET MESSAGES (and polled every so-many minutes) have been disconnected from GM (and not polled) because they at some random point start duplicating if GM is clicked.

I just re-read my Comment #1:
Early on, it looked like all deleted files were being reincarnated by REPAIR -- something like an incomplete deletion process was tripping things up -- but that quickly got fixed for pure DELETEs. I'm proposing that the underlying issue here is still in play -- INCOMPLETE DELETION of filtered files from the Inbox -- which then become reincarnated there because of their incomplete erasure (deletion) during (or following) the filtered move to the destination. And it's not like there were leftover entrails from previous versions. Some delete-by-filtered-MOVEs happened right now under TB 102.2.2 and then came back when REPAIR'd.

To clarify...
I'm running only POP3 accounts, and all share the one global Inbox under Local Folders, with several folders below that, and sub-folders under those. It so happens the filters in this case (and most others) deliver to folders on the first sub-folder level.

was just looking for an update

Note Windows 7 is almost two years out of support - time to upgrade. :) (unless you are running it to support users on antiquated OS)