RE: [otrs] Attachment wrongly labelled
When I switched over to the filesystem, all of my attachments were corrupt. They all appeared to be encoded wrong or something. I ended up having to switch back to the db for things to work again. ********************************* Jake Covert Infrastructure Analyst Electronic Data Systems PSIC Support Group (586) 986-9698 Work (586) 518-3859 Pager http://www.eds.com ********************************* Daniel Seifert wrote:
Am Mi, den 28.04.2004 schrieb Daniel Seifert um 15:07:
Am Mi, den 28.04.2004 schrieb Covert, Jake um 12:24:
Hi,
Are you attachments being stored in the db or the filesystem?
In the (mysql) database.
So would this problem go away if I switch over to store the attachments in the filesystem?
Hi all, I have a few questions regarding OTRS. 1. Is it possible to have a notification like this: ---------------------------- Send me a notification if a customer sends a follow up to any ticket in "My Queues" (even if I'm not the owner of the ticket). ---------------------------- 2. Is it possible to search for or have a Queue view that has all tickets modified today. 3. Is it possible to search incoming email for the string "Accounted time:" and then add that info to the ticket (ie. using PostMaster Filter Modules). Thanks Ivica
Am Do, den 29.04.2004 schrieb Covert, Jake um 14:09: Hi,
When I switched over to the filesystem, all of my attachments were corrupt. They all appeared to be encoded wrong or something.
I ended up having to switch back to the db for things to work again.
Do you experience the same problems as I do?
BTW, could somebody familiar with OTRS please comment on the attachment
problem? TIA
--
Daniel Seifert
Hi,
I've looked into the issue a bit more, as I got another email this
morning where the attachments were incorrectly sorted. I've been unable
to pinpoint the reason, though.
I get the mail with two attachments and one plaintext part. If I take a
look at the database, I see the following entries in the attachment SQL
table:
Article Filename Content Type Content
-----------------------------------------------------------------------------------------
12641 warp8.pdb text/plain; charset="iso-8859-15" [BLOB - 1,8 KB]
12641 file-1 application/octet-stream; name="warp8 Logo.pdb" [BLOB - 39,4 KB]
12641 warp8 Logo.pdb application/octet-stream; name="warp8.pdb" [BLOB - 27,2 KB]
As you can see, the attachments were sorted in in a completely wrong
order. Just an hour later I extracted the email from
~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address
and piped it into the system again (it doesn't matter whether via "cat
email | procmail" or "cat email | bin/PostMaster.pl"). And now the email
is displayed correctly:
Article Filename Content Type Content
-----------------------------------------------------------------------------------------
12646 warp8 Logo.pdb application/octet-stream; name="warp8 Logo.pdb" [BLOB - 39,4 KB]
12646 warp8.pdb application/octet-stream; name="warp8.pdb" [BLOB - 27,2 KB]
12646 file-1 text/plain; charset="iso-8859-15" [BLOB - 908 Bytes]
What puzzles me is that the iso-8859-15 part has actually been bigger
the first time the mail was processed, somewhere it seems to have lost
about 900 bytes?
Apart that the attachments are now stored correctly, the only other
significant change is the create_by column. For the "real" email this
was set to "2", whereas the resend email had this column set to "1". I
couldn't find the part in the source where this is set and I am not sure
what 1 and 2 mean. Taking a closer look at the database it seems that 2
is used for outgoing attachments and 1 for incoming? - which doesn't
really make sense as the first mail has not been an outgoing one.
Does anybody have any idea what might be going wrong here?
--
Daniel Seifert
On Tuesday, May 04, 2004 8:52 AM
Daniel Seifert
As you can see, the attachments were sorted in in a completely wrong order. Just an hour later I extracted the email from ~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address and piped it into the system again (it doesn't matter whether via "cat email | procmail" or "cat email | bin/PostMaster.pl"). And now the email is displayed correctly:
How did you formerly receive the eMail?
What puzzles me is that the iso-8859-15 part has actually been bigger the first time the mail was processed, somewhere it seems to have lost about 900 bytes?
Does a diff reveal anything?
Apart that the attachments are now stored correctly, the only other significant change is the create_by column. For the "real" email this was set to "2", whereas the resend email had this column set to "1". I couldn't find the part in the source where this is set and I am not sure what 1 and 2 mean. Taking a closer look at the database it seems that 2 is used for outgoing attachments and 1 for incoming? - which doesn't really make sense as the first mail has not been an outgoing one.
No, these are the user_ids that performed the action, ie. create or change. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Am Mo, den 10.05.2004 schrieb Robert Kehl um 14:15: Hi,
As you can see, the attachments were sorted in in a completely wrong order. Just an hour later I extracted the email from ~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address and piped it into the system again (it doesn't matter whether via "cat email | procmail" or "cat email | bin/PostMaster.pl"). And now the email is displayed correctly:
How did you formerly receive the eMail?
The same way. Actually it becomes more and more strange. I sent the
email again to me several times. On average, one out of three or four
emails are wrong, although
* they are created from exactly the same source
* the list of attachments is in the same order and has the same
links (except for the article number obviously)
* and the entries in article_attachments all look ok and identical
BUT every now and then one of the mail's attachments can not be opened
according to their name.
It's a mystery :-(
Could this be a very strange browser problem (I'm using Opera)? But my
colleague (using Safari, based on khtml/konqueror) reported the same
problem once. And as the screenshot I posted earlier shows, at least
once the attachments were actually sorted incorrectly.
I'm confused.
It hasn't happened lately, btw, although this may just be because we do
not generally receive a lot of mails with attachments. I've added
another backup rule to procmail prior to any modifications to the mails
and will keep an eye on it to get a 'clean' copy where I can reproduce
it.
--
Daniel Seifert
On Monday, May 10, 2004 3:10 PM
Daniel Seifert
Am Mo, den 10.05.2004 schrieb Robert Kehl um 14:15:
As you can see, the attachments were sorted in in a completely wrong order. Just an hour later I extracted the email from ~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address and piped it into the system again (it doesn't matter whether via "cat email | procmail" or "cat email | bin/PostMaster.pl"). And now the email is displayed correctly:
How did you formerly receive the eMail?
The same way.
I can hardly believe you're injecting your emails into OTRS by cat'ing them. Was it PostMasterPOP3.pl, or .procmailrc piping to Postmaster.pl or which other, usuable way?
Actually it becomes more and more strange. I sent the email again to me several times. On average, one out of three or four emails are wrong, although * they are created from exactly the same source * the list of attachments is in the same order and has the same links (except for the article number obviously) * and the entries in article_attachments all look ok and identical
Please enable debugging to get more info. Set $Self->{Debug} = 9; in Kernel/Config.pm and Kernel/System/PostMaster.pm.
BUT every now and then one of the mail's attachments can not be opened according to their name.
Thereby you mean, by clicking on xyz.pdf you open file-1, the text? As you described? Or are there other errors, too?
It's a mystery :-(
Life is, too. :-)
Could this be a very strange browser problem (I'm using Opera)? But my colleague (using Safari, based on khtml/konqueror) reported the same problem once. And as the screenshot I posted earlier shows, at least once the attachments were actually sorted incorrectly.
No, this I believe to be out of focus. To ensure this, cross-try the same ticket on several browsers next time you find one. Also, you should receive the very same result each time you
I'm confused.
Me three.
It hasn't happened lately, btw, although this may just be because we do not generally receive a lot of mails with attachments. I've added another backup rule to procmail prior to any modifications to the mails and will keep an eye on it to get a 'clean' copy where I can reproduce it.
Great idea. Could you post the recipe, just for the archives? This would help the more unexperienced users now and in future, I guess. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Am Mo, den 10.05.2004 schrieb Robert Kehl um 19:01: Hi,
As you can see, the attachments were sorted in in a completely wrong order. Just an hour later I extracted the email from ~otrs/var/INBOX.Backup.2004-05, changed the sender to my email address and piped it into the system again (it doesn't matter whether via "cat email | procmail" or "cat email | bin/PostMaster.pl"). And now the email is displayed correctly:
How did you formerly receive the eMail?
The same way.
I can hardly believe you're injecting your emails into OTRS by cat'ing them. Was it PostMasterPOP3.pl, or .procmailrc piping to Postmaster.pl or which other, usuable way?
procmail pipes it to PostMaster.pl, but that's actually the same as doing "cat email | procmail" ;-)
Please enable debugging to get more info. Set $Self->{Debug} = 9; in Kernel/Config.pm and Kernel/System/PostMaster.pm.
How much will this fill the logs?
BUT every now and then one of the mail's attachments can not be opened according to their name.
Thereby you mean, by clicking on xyz.pdf you open file-1, the text? As
Yes
you described? Or are there other errors, too?
No.
It hasn't happened lately, btw, although this may just be because we do not generally receive a lot of mails with attachments. I've added another backup rule to procmail prior to any modifications to the mails and will keep an eye on it to get a 'clean' copy where I can reproduce it.
Great idea. Could you post the recipe, just for the archives? This would help the more unexperienced users now and in future, I guess.
Well, it's the same rule as the other backup rule, I just copied it to
the top of the rc file to get a backup copy as I received the mail -
prior to adding headers and putting it through spamassassin and the
virus filter.
The rule is just
:0 c :
$SYS_HOME/var/INBOX.Backup.$MONTHFOLDER_plain
--
Daniel Seifert
On Monday, May 10, 2004 9:02 PM
Daniel Seifert
I can hardly believe you're injecting your emails into OTRS by cat'ing them. Was it PostMasterPOP3.pl, or .procmailrc piping to Postmaster.pl or which other, usuable way?
procmail pipes it to PostMaster.pl, but that's actually the same as doing "cat email | procmail" ;-)
You wouldn't believe how often I heard "I did nothing unusual", so: never mind!
Please enable debugging to get more info. Set $Self->{Debug} = 9; in Kernel/Config.pm and Kernel/System/PostMaster.pm.
How much will this fill the logs?
More. *g* Guess 3x. Watch it, please. Use an advanced syslog Konfiguration on, say: local5 or stuff to sort out the stream completely.. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Am Mo, den 10.05.2004 schrieb Robert Kehl um 22:25: Hi,
procmail pipes it to PostMaster.pl, but that's actually the same as doing "cat email | procmail" ;-)
You wouldn't believe how often I heard "I did nothing unusual", so: never mind!
I think most people on this list are in support, so I do know ;-)
Please enable debugging to get more info. Set $Self->{Debug} = 9; in Kernel/Config.pm and Kernel/System/PostMaster.pm.
How much will this fill the logs?
More. *g* Guess 3x. Watch it, please. Use an advanced syslog Konfiguration on, say: local5 or stuff to sort out the stream completely..
OK, but I expect it will take a few weeks until the next occurence (as I
said, we rarely get attachments).
By the way, with debug enabled I get a warning in Config.pm:
Debug: Config.pm ->Get('ArticleDir') --> /opt/otrs/var/article
Debug: Config.pm ->Get('DatabaseUserTable') --> system_user
Debug: Config.pm ->Get('DatabaseUserTableUserID') --> id
Debug: Config.pm ->Get('DatabaseUserTableUserPW') --> pw
Debug: Config.pm ->Get('DatabaseUserTableUser') --> login
Use of uninitialized value in concatenation (.) or string at
/opt/otrs/Kernel/Config/Defaults.pm line 1776.
The corresponding line reads:
print STDERR "Error: Config.pm No value for '$What' in Config.pm found!\n";
(function Get)
--
Daniel Seifert
Robert, I got another mail today with two attachments, which were sorted in correctly into the attachment database (according to phpmyadmin) but the links to the files are incorrect in ArticleView: shown in OTRS: actual files attach2.zip attach1.zip attach1.zip file-1 file-1 attach2.zip Let me know what debug info you need to sort this out. The one from postmaster.pl doesn't show anything regarding the attachments. Daniel Am Mo, den 10.05.2004 schrieb Robert Kehl um 19:01:
Please enable debugging to get more info. Set $Self->{Debug} = 9; in Kernel/Config.pm and Kernel/System/PostMaster.pm.
BUT every now and then one of the mail's attachments can not be opened according to their name.
Thereby you mean, by clicking on xyz.pdf you open file-1, the text? As you described? Or are there other errors, too?
It's a mystery :-(
Life is, too. :-)
--
Daniel Seifert
On Thursday, April 29, 2004 2:09 PM
Covert, Jake
When I switched over to the filesystem, all of my attachments were corrupt. They all appeared to be encoded wrong or something.
They aren't, they are just not meant to be opened right away from disk. We prepend the mime-type before saving an attachement to disk.
I ended up having to switch back to the db for things to work again.
Things will probably have been working all times. hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
participants (4)
-
Covert, Jake -
Daniel Seifert -
Ivica Mustapic -
Robert Kehl