I have a new install:osTicket Version

v1.10.1 (9ae093d)

— Up to date

Web Server Software

Microsoft-IIS/8.5

MySQL Version

5.5.45

PHP Version

5.6.31And I have "fileinfo" plugin.Using both DB and Filesystem storage I gave a problem where I can successfully upload files, but downloading any image always returns a corrupted download. "The image cannot be displayed because it contains errors".If I use a txt file it works fine, but any images are corrupted.I have also renamed the uploaded file in the filestore plugin to "filename.png" and the file correctly opens, so the Upload portion works, but the Download is getting scrambled.Does anyone have a suggestion for diagnosing this problem?This problem occurs in both the cliant and agent views.

Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance.  The more information you give us the better we will be able to assist you. Thank you.Too many variables right now.  How do you want it to be setup?  Filesystem or DB?If you installed the filesystem plugin... did you migrate the attachments from the DB to the filesystem after you installed it?  If not then you are getting them from the DB.  Or did you create a new ticket with an attachment after installing, configuration and enabling the plugin?

Thanks for your comment, The purpose of talking about both storage methods was to show that it's (probably) not a permissions issue as the same problem happens with both DB and FS storage.The ultimate goal is to get this to work with the FS storage. But for diagnostics sakes I've gone with the simpler out-of-the-box setup of the DB storage.I have made new tickets and new attachments for the DB after reverting back to the DB setup, yes.Thanks again, any further information I'll be glad to provide / find.

Since you want to use FS, install the plugin, configure it, and enable it.Migrate the attachments from the DB to the FS.Once that is complete:Let us know the settings that you use for the plugin.Let us know the permissions on the destination folder.Let us know your PHP temporary folder (and its permissions).

Sure:1. Base folder for attachment files: "uploads"2. IIS_IUSRS - modify permissions3. Default directory setup by WebPI when installing PHPWhen I email in a file it creates the directory structure to match the key from the URL, the file exists in the directory without a file extension. If I try to download the file from the website through either the agent view or guest view I get a corrupted download. If I rename the file to "xxxx.png" in Windows explorer then the image opens correctly on the server, but obviously doesn't download.

So that last time I checked (and its been a while) when you upload a file via PHP to Windows it puts the file in the PHP temporary folder as it uploads.  This folder has permissions on it.  The file inherits those permissions.Then when the file completes it is moved to its destination (DB or filesystem).  If it is moved to the file system it preserves the permissions on the file and puts it in the new location.  So if your IIS_IUSRS user only has modify, then it does not have read.

ntozier:Thanks for sticking with this, I appreciate it.I have reset permissions on the entire upload directory structure to "Everyone" Modify / Read but this has the same effect.I've downloaded the file from the server and loaded it in Notepad++ and also the "downloaded" file from my browser. The files are identical EXCEPT the downloaded file has an extra empty line in line 1. If I delete this empty line the image opens fine in all progams.Is it possible the windows PHP is inserting an extra line somehow?

eRRR....Everything is possible. :) I'll pass this thread along to he devs to take a look at.  Since I've never seen this happen.

@[deleted]Do the files have a create date in the database? (`ost_file` table -> `created` column)

Hello,I've just run all PHP files through GrepWin with the following pattern:\?>*\ZAnd replaced with an empty string.This found 314 files with trailing "?>" either with or without empty spaces.Removing this and putting the empty string in has made the download work correctly.I think this is the current best practice as per http://php.net/manual/en/language.basic-syntax.phptags.php so should be safe to leave it like this.Thanks for your help tracking this down.

It seems your server had issues with the whitespace after the closing tag in some files as I've been using attachments on FS and in the DB for a loooonnggggg time and have never experienced this (using CentOS). I'm glad you found and posted a resolution though!Cheers.

I'm guessing the combination of IIS and the particular PHP version have made it come to light.Love the system, thanks.

Write a Reply...