Opened 3 years ago
Closed 3 years ago
#1486383 closed Bugs (invalid)
Sending mail with attachment not possible
| Reported by: | beni | Owned by: | |
|---|---|---|---|
| Priority: | 3 | Milestone: | 0.4-beta |
| Component: | Core functionality | Version: | git-master |
| Severity: | critical | Keywords: | send mail attachment fail error |
| Cc: |
Description
Hello!
Whenever i compose a mail (be it fresh or be it a forwarded one), i am unable to send or even store it as draft.
Prior applying the patch from ticket #1486343 i got a session logout.
After applying the patch, nothing happens if i store the message as draft. If i send the mail, i get the error message: "[An internal error occured. Please try again.]"
The error log contains (thats the error from the patch from #1486343):
"[21-Dec-2009 16:00:47 +0100]: \$a_oldvars is no longer an array! Recreating array. It was previously:"
The PHP error log file is empty.
This may be corelated to ticket #1486324.
Change History (10)
comment:1 Changed 3 years ago by beni
comment:2 Changed 3 years ago by alec
- Milestone changed from later to 0.4-beta
Do you use suhosin? Disable it. Also, database encoding must be utf8.
comment:3 Changed 3 years ago by beni
Database encoding is UTF8.
I use suhosin, yes. What exactly needs to be disabled? session encryption?
comment:4 Changed 3 years ago by alec
- Resolution set to invalid
- Status changed from new to closed
Yes, session encryption.
comment:5 Changed 3 years ago by beni
- Resolution invalid deleted
- Status changed from closed to reopened
I disabled suhosin with the following php.ini settings:
[suhosin] suhosin.session.encrypt = Off
no change.
Even disabling the entire suhosin
using "suhosin.simulation=On"
does not work.
comment:6 Changed 3 years ago by beni
(i also cleared the RC database cache and messages tables, for a test, but does not help)
comment:7 Changed 3 years ago by beni
OK, news: it works for most attachments now.
However, the attachment i tested with has Umlauts in its name. Trying to store or send this fails like described in the original post.
comment:8 Changed 3 years ago by alec
Again. Make sure your database and session table uses UTF8. MySQL? SHOW CREATE TABLE session.
comment:9 Changed 3 years ago by beni
I Solved that problem too.
While the update script updated all tables to be UTF8, some fields in some tables remained ASCII. After i changed all tables collations and reset all fields encoding, everything works fine.
Thanks for your support!
comment:10 Changed 3 years ago by alec
- Resolution set to invalid
- Status changed from reopened to closed

Just to be complete: im on svn trunk revision 3185.