Hi,
I got a problematic attachment problem. Files attached are corrupted,
and picture files simple show a link to the picture, but no picture.
Sounds like deja-vu right?
I run RT 3.6.7 on a gentoo system, mysql-5.0.54.
The only things I can see in the logs that could indicate a problem
whatsoever is:
[Thu Dec 18 10:25:26 2008] [warning]: Encode::Guess failed: decoder is
undefined; fallback to iso-8859-1
(//var/www/localhost/rt-3.6.7/lib/RT/I18N.pm:436)
The tables in the RT database were latin1 charset. I tried to alter all
tables to UTF8, but then, attachments do not even get into the database
anymore (only their reference so to speak, but no binary data).
My RT_config.pm shows:
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless
(@EmailInputEncodings);
I also tried to move around the utf-8 and iso-8859-1 values, but nothing
better.
What else can I try to make them work? I saw quite some stuff about
updates on the DB when going to 3.8, but nothing that would concern me
apparently.
Thanks for any pointers.
fred
Hi,
I got a problematic attachment problem. Files attached are corrupted,
and picture files simple show a link to the picture, but no picture.
Sounds like deja-vu right?
I run RT 3.6.7 on a gentoo system, mysql-5.0.54.
The only things I can see in the logs that could indicate a problem
whatsoever is:
[Thu Dec 18 10:25:26 2008] [warning]: Encode::Guess failed: decoder is
undefined; fallback to iso-8859-1
(//var/www/localhost/rt-3.6.7/lib/RT/I18N.pm:436)
This warning string is issued when an incoming message has a text part
and this part has no information about encoding of the text. RT tries
to guess as it has to convert it into UTF8. It has nothing to do with
images or other binary attachments.
The tables in the RT database were latin1 charset. I tried to alter all
tables to UTF8, but then, attachments do not even get into the database
anymore (only their reference so to speak, but no binary data).
It was bad idea.
Proper upgrade to 3.8 can fix this. You can use half-measure and
convert Attachments.Content, ObjectCustomFieldValues.LargeContent and
sessions.a_session to corresponding BLOBs (LONGTEXT to LONGBLOB, TEXT
to BLOB and so on).
My RT_config.pm shows:
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless
(@EmailInputEncodings);
Again, it’s related to text parts only. When RT sees no information
about encoding it uses these encodings to guess encoding of the email.
I also tried to move around the utf-8 and iso-8859-1 values, but nothing
better.
What else can I try to make them work? I saw quite some stuff about
updates on the DB when going to 3.8, but nothing that would concern me
apparently.
Thanks for any pointers.
fred
Best regards, Ruslan.
Hello Ruslan,
Yes, that’s what I just ended up doing. I transformed the longtext of
the Attachment.content to longblob, and attachments are working now 
Thank you.
fred
Ruslan Zakirov wrote:> On Thu, Dec 18, 2008 at 4:05 PM, Fred Blaise fredb@modernp.com wrote:
Hi,
I got a problematic attachment problem. Files attached are corrupted,
and picture files simple show a link to the picture, but no picture.
Sounds like deja-vu right?
I run RT 3.6.7 on a gentoo system, mysql-5.0.54.
The only things I can see in the logs that could indicate a problem
whatsoever is:
[Thu Dec 18 10:25:26 2008] [warning]: Encode::Guess failed: decoder is
undefined; fallback to iso-8859-1
(//var/www/localhost/rt-3.6.7/lib/RT/I18N.pm:436)
This warning string is issued when an incoming message has a text part
and this part has no information about encoding of the text. RT tries
to guess as it has to convert it into UTF8. It has nothing to do with
images or other binary attachments.
The tables in the RT database were latin1 charset. I tried to alter all
tables to UTF8, but then, attachments do not even get into the database
anymore (only their reference so to speak, but no binary data).
It was bad idea.
Proper upgrade to 3.8 can fix this. You can use half-measure and
convert Attachments.Content, ObjectCustomFieldValues.LargeContent and
sessions.a_session to corresponding BLOBs (LONGTEXT to LONGBLOB, TEXT
to BLOB and so on).
My RT_config.pm shows:
@EmailInputEncodings = qw(utf-8 iso-8859-1 us-ascii) unless
(@EmailInputEncodings);
Again, it’s related to text parts only. When RT sees no information
about encoding it uses these encodings to guess encoding of the email.
I also tried to move around the utf-8 and iso-8859-1 values, but nothing
better.
What else can I try to make them work? I saw quite some stuff about
updates on the DB when going to 3.8, but nothing that would concern me
apparently.
Thanks for any pointers.
fred