> Re-reading the previous posts, I get the impression you're trying to
> open the files by directly clicking on them? This won't work, as it's
> not meant to be that way. Click on them in OTRS, this should work. Does
> it?
I have tried both opening the file from the OTRS dialog and in the file system, and
have noted the
following:
1. The attached files are properly registered as attachments and can be selected in
OTRS dialogs
(e.g. History). Opening them within an OTRS dialog results in an error, as the
associated program
(e.g. Winzip for zip files, IExplore for images etc.) indicates the file is "corrupt"
(i.e. could
not be read).
2. The system has been set up with the option "TicketStorageModule =
Kernel::System::Ticket::ArticleStorageFS", so the attachments are subsequently visible
in the
respective file system folders (i.e.C:/otrs/var/article). The files are not of correct
(initial)
size, and cannot be opened or executed correctly when selecting them directly from the
file system
(i.e. by means of a file manager such as the Windows Explorer).
Selecting attachments from the file system does not work because the file stored by
OTRS has a
header prepended to the original file indicating the "mime type".
For ZIP files, the following is prepended:
application/x-zip-compressed<CRLF>
For PDF files, the following is prepended:
application/pdf<CRLF>
For EXE files, the following is prepended:
application/octet-stream<CRLF>
<CRLF> indicates the "carriage return/line feed" pair.
Selecting the attachment in a OTRS dialog activates the associated application, which
in turn cannot
resolve invalid information in the "header" of the file.
I have investigated further the source code for database/file system processing and
determined that
specifying binary mode when storing or retrieving attachments is required. The idea
was to
suppress any translation of character data content. To test this, I changed the source
code as
follows:
in module otrs\Kernel\System\Ticket\ArticleStorageFS.pm:
sub WriteArticlePart {
...
...
# --
# write attachment to fs
# --
if (open (DATA, "> $Param{Path}/$Param{Filename}")) {
# Branko 18.3.2004 set binary mode for stored data
binmode(DATA);
print DATA "$Param{ContentType}\n";
print DATA $Param{Content};
close (DATA);
return 1;
}
else {
...
...
sub GetArticleAttachment {
...
...
my %Data;
my $Counter = 0;
$Data{Filename} = $Index{$Param{FileID}};
if (open (DATA, "< $Self->{ArticleDataDir}/$ContentPath/$Param{ArticleID}/
$Index{$Param{FileID}}")) {
# Branko 19.3.2004 set binary mode for stored data
binmode(DATA);
while (<DATA>) {
$Data{ContentType} = $_ if ($Counter == 0);
$Data{Content} .= $_ if ($Counter > 0);
$Counter++;
}
close (DATA);
chomp ($Data{ContentType});
return %Data;
}
else {
...
...
Now I can access properly all attachment types stored in the file system, by means of
the OTRS
dialogs. The correction to the software may be OS specific.
Kindly comment on this.
Regards
Branko Zecevic
_______________________________________________
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 oder Consulting für Ihr OTRS System?
=> http://www.otrs.de/
