On Wed, 17 Mar 2004 21:35:28 +0100 Robert Kehl wrote:

On Friday, March 12, 2004 9:15 AM Branko Zecevic wrote:

...

The attached files are properly registered as attachments and can be selected in OTRS dialogs (e.g. History). Opening them results in the same error, as the associated program (e.g. Winzip for zip files) indicates the file is corrupt.

As mentioned earlier, after upload the size of the file is incorrect (larger). We assume the files are stored in text format and not as "binary" files.

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?

Sorry I did not get all of the previous posts, because I subscribed to the list yesterday, but this sounds like the error I am getting. The prepended LF character. reagards Roland

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

Sorry for not having recognized you're talking about a 1.1.3 installation. An upgrade to 1.2.2 will certainly solve the error of not In my posting today I described a change to the source code of the software that helped us with our tests, namely the setting of "binary mode" when storing/retrieving attachments to/from the file system.

thoroughly. Nonetheless you won't and shouldn't be able to open them directly in a file manager. This I now recognize, given the fact that a "header" is prepended to the attachment data stream.

Regards Branko Zecevic