Closed Bug 1182686 Opened 9 years ago Closed 6 years ago

Unable to view attachment moved to account with maildir store

Categories

(MailNews Core :: Backend, defect)

Product:
MailNews Core
Component:
Backend
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1430480

People

(Reporter: gecko, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

Open message with attachment in IMAP mail account #1 (mbox or maildir store)
Double click on attachment and view it.
Close attachment
Close message
Move message to IMAP mail account #2 (maildir store)
Open message in IMAP mail account #2 (maildir store)
Double click on attachment
Dialog box pops up saying "This attachment appears to be empty.  Please check with the person who sent this. Often company firewalls or antivirus programs will destgroy attachments."
View source for message.  Attachment appears in source.
Turn off sync for folder containing message in IMAP mail account #2 (maildir store)
Turn on sync for folder containing message in IMAP mail account #2 (maildir store)
Messages in folder download
Open message with attachment in IMAP mail account #2 (maildir store)
Double click on attachment and view it.

Tested on 38.0.1


Actual results:

Dialog box pops up saying "This attachment appears to be empty.  Please check with the person who sent this. Often company firewalls or antivirus programs will destgroy attachments."


Expected results:

Attachment should have opened for viewing in proper program same as before moving the message and after turning sync on and off.
Blocks: maildirblockers
Severity: normal → major
Component: Untriaged → Backend
Product: Thunderbird → MailNews Core
Ralph, do you still see this when using a curent release or beta version?
Flags: needinfo?(gecko)
I just tested with the current release channel 45.6.0 and it still fails in exactly the same way.
Flags: needinfo?(gecko)
I still can confirm this bug in 52.0 / 52.0.1.

These scenarios are working without problems and attachments can be opened after procedure:
1. Moving or copying a mail from an IMAP/maildir folder to another folder in the same account.
2. Moving or copying a mail from an IMAP/maildir folder to Localfolders/Mbox store.

Not working is the following scenario:
Moving or copying a mail from one IMAP/maildir account to another IMAP/maildir ACCOUNT.

In ALL scenarios the resulting mail source code is completely the same - the MIME parts are NOT missing.
(In reply to AlexIhrig from comment #3)
> Not working is the following scenario:
> Moving or copying a mail from one IMAP/maildir account to another
> IMAP/maildir ACCOUNT.
> 
> In ALL scenarios the resulting mail source code is completely the same - the
> MIME parts are NOT missing.

Interesting is, that moving or copying the (in maildir store) not working messages again to a Mbox store is leading to completely working messages and attachments.

Conclusion: no data loss; only loss of function
Additional information:

Thunderbird 52.3.0
* If you are forwarding affected messages, the attachments can be opened again from the mail compose window.
* If you are repairing / recreating the folder index (*.msf), the attachments can be opened again.
Doing some tests, I'm able to reproduce one more behaviour:

When a filter is applied to the inbox, which is copying or moving messages, there is a difference:
* before Junk-filter processing --> the attachments in the resulting copy are working
* after Junk-filter processing --> the attachments in the resulting copy are not working

In all cases repairing *.msf fixes the problem
This was under the "meta" bug list for maildir, bug 845952. Actually, I think this is a duplicate of bug 1430480. However, I need to look closer at the filtering scenario, before/after junk processing described in comment 6, which is also pointed out in bug 1430480.
(In reply to AlexIhrig from comment #6)
> Doing some tests, I'm able to reproduce one more behaviour:
> 
> When a filter is applied to the inbox, which is copying or moving messages,
> there is a difference:
> * before Junk-filter processing --> the attachments in the resulting copy
> are working
> * after Junk-filter processing --> the attachments in the resulting copy are
> not working

I am working on a similar bug 1430480, possibly a duplicate of this bug. However, I am not able to duplicate the filtering problem you describe when the filter moves or copies the message within the same account. You don't say if maybe you are moving/copying the message to another account using the filter, just that the problem only occurs if filter occurs after junk processing. Could you clarify this?

Also, what version of TB and type of system are you running on?  Thanks!
Flags: needinfo?(AlexIhrig)
Tests done today with Thunderbird 52.6.0 on Windows 10 Pro 64-Bit. All results are reproduceable:

Manually copied and/or moved mail without filtering:
- from one maildir-account to another maildir-account: attachments are working
- from one folder in maildir-account to another folder in the same maildir-account: attachments are working

Message sent and received in maildir-account inbox. Filter (copy message) applied automatically before junk-processing:
- from one maildir-account to another maildir-account: attachments are working
- from one folder in maildir-account to another folder in the same maildir-account: attachments are working

Message sent and received in maildir-account inbox. Filter (copy message) applied automatically _AFTER_ junk-processing:
- from one maildir-account to another maildir-account: attachments are working
- from one folder in maildir-account to another folder in the same maildir-account: attachments _NOT_ working

This is a little bit weired, because of differing results in my comment #3.
Flags: needinfo?(AlexIhrig)
I just tested with 52.7.0 Windows 10 Pro 64-bit.  Still fails manually copying email with attachment to a different account that uses maildir for local storage.  Not sure why Alexihrig is seeing it working now - weird as he says.  It does seem like this is related to bug 1430480 but for me it doesn't happen on any server to imap server copy only when the destination server is backed locally by maildir.  Never happens if destination server is backed locally by mbox.
confirmed
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just now saw it too when copy between maildir based servers and ok on same server using win7 tb 52.7. I will need to try the windows beta (see bug 1430480 comment 98) to know if it really fixes it. I tested it before while working on bug 1430480, mostly with filters doing the copy, and it seemed to fix the problem on linux.
Seems OK with tb beta 60.0b4 (32-bit) in win7. Attachment ok after copy at maildir destination on other server.
Tested with 60.0b4 on Windows 10 Pro 64-bit and it now works properly.  Attachments copied to IMAP account backed locally by maildir are now displayed instead of producing an error dialog when trying to open them.
Confirmed - Bug seems to be fixed with Thunderbird 60.0 Beta 4.
We can also confirm that the patch in bug 1430480 fixes the bug for us.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.