Bugzilla

Those prefs are also used in mozilla/firefox code for caching, I think. But tb and ff are completely separate programs and don't share code, AFAIK.
Not sure what "agressive disk caching" you are referring to. The only disk cache tb uses is when you store messages for offline use and it create mbox files containing each folder's messages. 

Anyhow, we might just close this bug as invalid but I think it has uncovered a bug. With ram caching turned off like you had it, saving an attachment should still work. I can make a one line change to the code to make it work so the save works with mem caching disabled. The change forces a full message fetch instead of a fetch by parts. However I haven't yet determined why it is fetching by parts. As you found, when you open the attachment into an application, it fetches it correctly and, in that case, fetches the whole message like it should.

Those prefs are also used in mozilla/firefox code for caching, I think. But tb and ff are completely separate programs and don't share code, AFAIK.
Not sure what "agressive disk caching" you are referring to. The only disk cache tb uses is when you store messages for offline use and it create mbox files containing each folder's messages. 

Anyhow, we might just close this bug as invalid but I think it has uncovered a bug. With ram caching turned off like you had it, saving an attachment should still work. I can make a one line change to the code to make it work so the save works with mem caching disabled. The change forces a full message fetch instead of a fetch by parts. However I haven't yet determined why it is fetching by parts. As you found, when you open the attachment into an application, it fetches it correctly and, in that case, fetches the whole message like it should.

Edit: The fetch by parts only fetches the message headers and mime headers. If it fetched the actual attachment there would be no problem with fetch by parts.

Those prefs are also used in mozilla/firefox code for caching, I think. But tb and ff are completely separate programs and don't share code at runtime, AFAIK. But they do share a lot of source code.
Not sure what "agressive disk caching" you are referring to. The only disk cache tb uses is when you store messages for offline use and it create mbox files containing each folder's messages. 

Anyhow, we might just close this bug as invalid but I think it has uncovered a bug. With ram caching turned off like you had it, saving an attachment should still work. I can make a one line change to the code to make it work so the save works with mem caching disabled. The change forces a full message fetch instead of a fetch by parts. However I haven't yet determined why it is fetching by parts. As you found, when you open the attachment into an application, it fetches it correctly and, in that case, fetches the whole message like it should.

Edit: The fetch by parts only fetches the message headers and mime headers. If it fetched the actual attachment there would be no problem with fetch by parts.

Those prefs are also used in mozilla/firefox code for caching, I think. But tb and ff are completely separate programs and don't share code at runtime, AFAIK. But they do share a lot of source code.
Not sure what "agressive disk caching" you are referring to. The only disk cache tb uses is when you store messages for offline use and it create mbox files containing each folder's messages. 

Anyhow, we might just close this bug as invalid but I think it has uncovered a bug. With ram caching turned off like you had it, saving an attachment should still work. I can make a one line change to the code to make it work so the save works with mem caching disabled. The change forces a full message fetch instead of a fetch by parts. However I haven't yet determined why it is fetching by parts. As you found, when you open the attachment into an application, it fetches it correctly and, in that case, fetches the whole message like it should.

Edit: The fetch by parts only fetches the message headers and mime headers and the message body (which is empty for the test message). If it fetched the actual attachment there would be no problem with fetch by parts. Also, looked at your log file and I see the exact same thing here when I record the log with your test message. Also, just to be clear, I understood that the attachment to to test message was a pdf with all A's so I open it to a text editor application and it is fetched OK only then (but not when saving).