Hi,
I found the answer.
/Kernel/System/DB/oracle.pm
sub LoadPreferences {
my $Self = shift;
my %Param = @_;
# db settings
$Self->{'DB::Limit'} = 0;
$Self->{'DB::DirectBlob'} = 0;
$Self->{'DB::QuoteSingle'} = '\'';
$Self->{'DB::QuoteBack'} = 0;
$Self->{'DB::QuoteSemicolon'} = '';
$Self->{'DB::Attribute'} = {
LongTruncOk => 1,
LongReadLen => 3*1024*1024,
^^^^^^^^^^^^
I changed this to 6 and voila, it downloaded the file with the correct size.
I filed this bug at 07/11 as a critical bug. I think it's critical
because it is for me.
Nobody has answered for that so far. I was unable to get back the
attachment bigger than 3Mb till this moment.
Hopefully I'm a coder and I familiar with Perl and Oracle as well to dig
the whole system and find a bug like this.
But I know. There is no such thing like free lunch.
Regards., Sandor
Sándor Fehér írta:
Some additions. I checked if the stored content is consistent in
article_attachment table.
It is. I checked the content's size with a small pl/sql script and it
shows the right value in both cases.
So there is something in the web framework i think.
Regards.,Sandor
Sándor Fehér írta:
I changed the backend to FS it works fine.
If I set WebUploadCacheModule: FS then it shows the correct size of the
attachment but still unable to dowload it with full size.
If I set WebUploadCacheModule: DB and manually add a ticket then it
shows 3Mb instead of original size and retrieves 3Mb.
If I send a mail with the attachment around 6Mb it shows as 6Mb but
retrieves only 3Mb.
Regards,Sandor
Sándor Fehér írta:
Hi,
It did not let me sleep. I investigated the process.
I put a little hack into the ArticleStorageDB.pm which provides me the
size of the attachment read.
It was correct. The second turn I put the whole encoded content into a
temp file.
It's size also looked me good. Then I run
perl -w -MMIME::Base64 -ne 'print decode_base64($_)' <oo.txt >oo.pdf
The result is then the decode process cut the output at 3 Mb however
it's 3.5 Mb.
It happened at the same size 3104874. It's a kind of magic number. I
did not find any restrictions related to MIME::Base64.
Of course I double checked the filesystem allocation as well.
For a different approach I encoded a tgz (quite big, around 35 Mb)
then decoded it again
It was perfect.
So I suspect there is "something" in the stored content which drives
decode_base64 onto wrong way.
Regards.,Sandor
Hi,
I have an urgent issue. It's unable to download attachments bigger than
3 Mb.
If I click on the attachment link ie show the download size as 3 Mb and
downloads this as a 3 Mb instead of the original size.
TicketZoom shows it's size correctly. Due to this problem I unable to
access some important files.
ArticleStorage backend is DB. DB is Oracle 10g. In article_attachments
table show also the correct size in content_size column.
Thanks a lot.
Regards., Sandor
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support or consulting for your OTRS system?
=> http://www.otrs.com/
--
Üdvözlettel/Kind Regards, Fehér Sándor
...Fehér Sándor... --- ....Sandor Feher....
fejlesztési vezető --- development manager
Blue System Kft. --- Blue System Ltd.
mailto:[EMAIL PROTECTED] http://www.bluesystem.hu
[ - real men don't click - ]
------------------------------------------------------------------------
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support or consulting for your OTRS system?
=> http://www.otrs.com/
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support or consulting for your OTRS system?
=> http://www.otrs.com/
