When you say "corrupted", what exactly do you mean?

I'm having the same problem. osTicket (v1.8.1.2), debian 7.4, apache 2.2.22, php 5.4.4, using the filesystem attachment plugin.When a user sends an email with attachments, they are properly added to the ticket system and they are on the filesystem, however, when the staff tries to open them from the web interface, they are corrupt.I looked at the files in the filesystem and the database entry and noticed that the file size value in the database is incorrect.For example: small image/gif file from a html signature is showing a file size of 1586 bytes:# ls -la m/mo9twVkFS0x4fMgeF0b7PZv0B7TtqYW0-rw-r--r-- 1 root www-data 1586 Apr 26 11 m/mo9twVkFS0x4fMgeF0b7PZv0B7TtqYW0However, the database entry in the ost_file db table shows a size of 1249 bytes.I compared all other attachments and all sizes in the ost_file table are incorrect.Replacing the value in the ost_file table with the correct one solves the issue and the file can be properly downloaded from the web interface and the file is not corrupt (which makes sense as the end of the file isn't missing).I tried enforcing calculating the filesize when saving it in include/class.file.php by commenting out the condition in line 311, but that did not make any difference. Somewhere/somehow, the save function receives an incomplete data stream.I'm new to osticket and don't know the internal structure yet. Any advice or help finding the cause of this bug would be appreciated. Thanks.

Can anyone with the issue verify if in their php.ini file, the `mbstring.func_overload` is set to a non-zero value. If so, can anyone verify if the patch here (https://github.com/osTicket/osTicket-1.8/pull/811) addresses this issue?

My cli php ini is set to mbstring.func_overload = 6, my apache php ini is set to 0.I applied the patch and can confirm that file attachments now use the correct size in the db and can be downloaded from the web interface.Uploading a new file (gif file) via webinterface failed on first attempt and creates a ticket note about the failure. It created an entry in the _file table with the correct file size, flagged as 'D' backend, but appeared to have failed to migrate it into the proper 'F' backend and got subsequently cleaned up as it didn't have a reference.I repeated the test with another file which worked and with the same file again which worked as well.Uploading the same file via webinterface creates a new reference to the existing file and works.Deduplication of files sent via mail doesn't seem to work. A new entry in the _file table has been created for an attachment which exists already with the same signature. Deduplication from uploads via the web interface still works. (This highlighted a small issue with the dedup though. Even though the files were the same, the filenames were not. Wouldn't it be better to store the filename in the _attachment table as well and use that in the web ticket display to retain different filenames? I suggest to still store the original filename in the _file table and fall back to that one for backwards compatibility though.)Thanks a lot for identifying and fixing this issue!