Message attachments, relocated with Tbird in Dovecot maildir store, not openable; reversible by moving BACK to inbox?
I run
dovecot --version
2.3.17.1 (476cd46418)on
lsb_release -rd
Description: Fedora release 35 (Thirty Five)
Release: 35mail store is maildir
mail_location = maildir:/data/vmail/%d/%n/Maildir:CONTROL=/data/vmail/%d/%n/_control:INDEX=/var/vmail-index/%d/%n:LAYOUT=fs:UTF-8front-end client is
thunderbird --version
Thunderbird 91.7.0also on
lsb_release -rd
Description: Fedora release 35 (Thirty Five)
Release: 35mail is delivered to the store via lmtp transport from a Postfix agent
mail, with attachments (e.g., .PDF) is received OK it's readable, attachments can be opened and/or saved to disk\
if, in TBird client, i move the message to any other folder in the IMAP hierarchy, the message relocates, as expected.
the message itself is still readable, and _appears_ to have the attachment.
but, attempting to OPEN the *attachment*, with e.g. Okular, from within the relocated message pops up a dialog,
"Could not open file:///tmp/pid-28435/manual_13542AE.pdf"and saving it to Desktop,
ls -al manual_13542AE.pdf
-rw-r--r-- 1 pgnd pgnd 27 Apr 1 06:01 manual_13542AE.pdf
file manual_13542AE.pdf
manual_13542AE.pdf: datathen opening it similarly returns
"Could not open file:///home/pgnd/Desktop/manual_13542AE.pdf."Moving the message, via TBird, **BACK** to the Inbox, cures the problem -- -- I can immediately, again, open & save the attachments.
This 'feels' like cache management misconfiguration to me. Not sure whether in Tbird &/or Dovecot, or what to look for specificially.
Hints as to cause/fix of this attachment issue? Or event what/where, specifically, to log?
Le 01/04/2022 à 12:17, PGNet Dev a écrit :
This 'feels' like cache management misconfiguration to me. Not sure whether in Tbird &/or Dovecot, or what to look for specificially.
Hints as to cause/fix of this attachment issue? Or event what/where, specifically, to log?
I see same symptoms when opening a mail in thunderbird 2 or 3 weeks after I received it, without moving it in another folder. Burt using "repair folder" in TB, I get it back, so for me it looks more like a TB cache problem.
I see same symptoms when opening a mail in thunderbird 2 or 3 weeks after I received it, without moving it in another folder. Burt using "repair folder" in TB, I get it back, so for me it looks more like a TB cache problem.
hm. 'repair' here does nothing for me.
looking at my current TBird settings for disk/cache/offline/subscription,
browser.cache.check_doc_frequency, 1
browser.cache.compression_level, 0
browser.cache.disk.capacity, 0
browser.cache.disk.enable, false
browser.cache.disk.max_entry_size, 51200
browser.cache.disk.smart_size.enabled, false
browser.cache.disk.smart_size.first_run, false
browser.cache.disk.smart_size.use_old_max, true
browser.cache.disk_cache_ssl, false
browser.cache.memory.enable, false
browser.cache.memory.max_entry_size, 5120
browser.cache.offline.capacity, 512000
browser.cache.offline.enable, true
mail.server.default.offline_download, false
mail.server.default.autosync_offline_stores, false
offline.download.download_messages, 2
mailnews.offline_sync_mail, false
mailnews.offline_sync_news, false
mailnews.offline_sync_send_unsent, false
mailnews.offline_sync_work_offline, false
offline.autoDetect, false
offline.send.unsent_messages, 2
offline.startup_state, 0
mail.server.default.check_all_folders_for_new, true
mail.check_all_imap_folders_for_new, true
mail.imap.hide_unused_namespaces, false
mail.imap.auto_unsubscribe_from_noselect_folders, false
mail.server.default.using_subscription, false
mail.imap.hide_unused_namespaces, false
mail.server.default.override_namespaces, truei _thought_ that^^ should eliminate local caching.
sounds like, perhaps, i've misconfigured, or am missing, something ...
4/1/22
I see same symptoms when opening a mail in thunderbird 2 or 3 weeks after I received it, without moving it in another folder. But using "repair folder" in TB, I get it back, so for me it looks more like a TB cache problem.
I've still not managed to solve for this problem; 'repair' doesn't fix it.
Anyone here have a reliable fix -- either on the TBird &/or Dovecot sides -- to get these subfoldered attachments openable/readable? Ideally without the need for manual intervention each time?
The issue, again is:
Email with attachments (e.g., pdf) I receive to an account INBOX can be accessed in TBird/Linux with no problems.
Dubl-Click on the attachment, and it opens in app -- e.g. pdfs open in Okular.
Saving the attachment to Desktop,
ls -al /home/pgnd/Desktop/SomeFile.pdf
-rw-r--r-- 1 pgnd pgnd 197K May 18 07:49 /home/pgnd/Desktop/SomeFile.pdfAll good.
If I move the message , including attachment, to any other (sub)folder, and try to open the attahment,
I get the usual open dialog,
You have chose to open:
SomeFile.pdf
which is: Portable Document Format (PDF) (66.7 KB)
from: imap://mx.example.com:993
What should Thunderbird do with this file?
[X] Open with 'Okular (default)'which, on 'OK', does open Okular -- with an Error:
Error -- Okular
Could not open file:///tmp/pid-59993/SomeFile.pdfchecking
ls -altr /tmp/pid-59993/SomeFile.pdf
-r--------+ 1 pgnd pgnd 27 May 18 07:46 'SomeFile.pdf'If I move the message BACK to imap INBOX, and open/save attachment it's good again.
Thunderbird is not correctly retrieving the attachment when the message is not in imap:INBOX.
On 5/18/22 8:00 AM, PGNet Dev wrote:
4/1/22
I see same symptoms when opening a mail in thunderbird 2 or 3 weeks after I received it, without moving it in another folder. But using "repair folder" in TB, I get it back, so for me it looks more like a TB cache problem.
I've still not managed to solve for this problem; 'repair' doesn't fix it.
Anyone here have a reliable fix -- either on the TBird &/or Dovecot sides -- to get these subfoldered attachments openable/readable? Ideally without the need for manual intervention each time?
with Tbird cache(s) DISabled,
browser.cache.disk.enable = false
browser.cache.memory.enable = false
browser.cache.offline.enable = falsethis issue continues.
That suggests that this is NOT a TBird cache issue?
Reading,
https://doc.dovecot.org/configuration_manual/mail_cache_settings/
https://doc.dovecot.org/settings/core/#core_setting-mail_cache_fieldsI suspect these params in Dovecot
mail_cache_fields =
mail_always_cache_fields =
mail_never_cache_fields =
mail_cache_unaccessed_field_drop =, which atm for my install are @default values, may need to be modified.
if so? to what?
On Wed, 18 May 2022, PGNet Dev wrote:
checking
ls -altr /tmp/pid-59993/SomeFile.pdf -r--------+ 1 pgnd pgnd 27 May 18 07:46 'SomeFile.pdf'
This may or may not get you closer to the solution, but out of curiosity, what's in the 27 bytes worth of data? And are those quotes really there?
Joseph Tam jtam.home@gmail.com
On 5/18/22 4:23 PM, Joseph Tam wrote:
On Wed, 18 May 2022, PGNet Dev wrote:
checking
ls -altr /tmp/pid-59993/SomeFile.pdf -r--------+ 1 pgnd pgnd 27 May 18 07:46 'SomeFile.pdf'
This may or may not get you closer to the solution
After enabling the memory cache per prior suggestion, haven't had any more issue. So far.
but out of curiosity, what's in the 27 bytes worth of data?
Binary garbage of some sort. In this failure case, it _is_ always exactly 27 bytes.
And are those quotes really there?
Depends on whether the real filename had spaces in it, before I changed it to "SomeFile" ... Doesn't matter what the filename is, in any case.
On Wed, 18 May 2022 13:23:20 -0700 (PDT), Joseph Tam jtam.home@gmail.com wrote:
This may or may not get you closer to the solution, but out of curiosity, what's in the 27 bytes worth of data? And are those quotes really there?
According to Bugzilla, it is:"The 27 bytes are the encoded string "attachment will be downloaded on demand" (approximately)."
-- Virgo Pärna virgo.parna@mail.ee
On Fri, 1 Apr 2022 06:17:15 -0400, PGNet Dev pgnet.dev@gmail.com wrote:
and saving it to Desktop,
ls -al manual_13542AE.pdf -rw-r--r-- 1 pgnd pgnd 27 Apr 1 06:01 manual_13542AE.pdf
Try enabling memory cache and setting memory cache size larger,then attachment size. That 27 byte file size is familiar.
-- Virgo Pärna virgo.parna@mail.ee
On 5/18/22 9:51 AM, Virgo Pärna wrote:
ls -al manual_13542AE.pdf -rw-r--r-- 1 pgnd pgnd 27 Apr 1 06:01 manual_13542AE.pdf
Try enabling memory cache and setting memory cache size larger, then attachment size. That 27 byte file size is familiar.
in Tbird, I set
browser.cache.memory.enable true browser.cache.memory.capacity 512000 browser.cache.memory.max_entry_size 51200
, restarted and ... my attachments now open correctly in any/all subfolders.
not what i expected; i'm not at all clear _why_ ENanbling cache solves this problem. glad that it does, though.
cheers!
On Wed, 18 May 2022 13:18:31 -0400, PGNet Dev pgnet.dev@gmail.com wrote:
, restarted and ... my attachments now open correctly in any/all subfolders.
not what i expected; i'm not at all clear _why_ ENanbling cache solves this problem. glad that it does, though.
Check https://bugzilla.mozilla.org/show_bug.cgi?id=1589649It seems to be some problem with current codepage of Thunderbird. Only in my case it also failed to open in application. And it creates magic 27 byte files..
-- Virgo Pärna virgo.parna@mail.ee
On 5/19/22 3:12 AM, Virgo Pärna wrote:
Check https://bugzilla.mozilla.org/show_bug.cgi?id=1589649 It seems to be some problem with current codepage of Thunderbird. Only in my case it also failed to open in application. And it creates magic 27 byte files..
thx for the link.
of course, @ bug, "won't fix". sigh.
here, my cache _were_ all turned off, and offline was off, too.
in the end, per your comments, I've settled on
browser.cache.memory.capacity" 40000000 browser.cache.memory.enable" true browser.cache.memory.max_entry_size 40000000 mail.imap.mime_parts_on_demand" false mail.server.default.mime_parts_on_demand false
easily deployed to user.js to prevent this for others.
thx!
On Thu, 19 May 2022 07:07:34 -0400, PGNet Dev pgnet.dev@gmail.com wrote:
thx for the link.
of course, @ bug, "won't fix". sigh.
Actually, there is hope now. I newer thought, that the fact,that message was in subfolder, was relevant. It sound like, they were finally able to duplicate the error.
-- Virgo Pärna virgo.parna@mail.ee
participants (4)
-
Erwan David
-
Joseph Tam
-
PGNet Dev
-
Virgo Pärna