News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

upgrade.php loses mime_type

Started by Krashsite, February 27, 2014, 02:45:57 PM

Previous topic - Next topic

Sir Osis of Liver

Underdog found this in a forum we've been working on, thought it worth a mention.  When upgrading from 1.1.19 to 2.0.7, upgrade.php does not transfer mime_type in smf_attachments from old table to new.  This causes image files to fail in IE only, does not affect other browsers.  We see this in IE8 and IE11.  Restoring mime_type data fixes problem.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Chen Zhen


I can confirm this issue.

  Some browsers do not know how to use the files that are void of file extensions therefore are unable to use the attachments files without the given mime type. When upgrading from the SMF 1.1X branch to the SMF 2.0.X branch this db data is not being transferred to the appropriate db column.   

  I made a tool (for images only) to fix the issue for now but imo the problem needs to be addressed.

Regards.

My SMF Mods & Plug-Ins

WebDev

"Either you repeat the same conventional doctrines everybody is saying, or else you say something true, and it will sound like it's from Neptune." - Noam Chomsky

Kays

I'm a little confused here. ???

Although the topics title is "upload.php loses mime_type", you refer to upgrade.php. Which is it?

Secondly, it is normal to encounter both 1.x as well as 2.0 attachment tables where there will be no mime type entered for image attachments. Commonly, these will be databases with attachments added before file encryption was enforced. So even if upgrade.php does copy(?) the mine type. There will be occasions where there is none to copy.

Browser and mime type compatibility is sorted out in the download() function in Display.php. If this is another case of IE being fussy. Then there is probably where it would need to be addressed.

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

Chen Zhen


  The file names within the SMF 1.1.X installation were encrypted and void of file extensions. The SMF 2.0.7 upgrade altered the attachments table by adding the fileext & mime_type columns to the table for its native operation. It fills the necessary data into the fileext column but fails to enter/fill the necessary mime_type data which can easily be determined from the file extension using a simple array & loop.  Some browsers need the mime type data to be in the header content-type else the images will not be displayed. IE is one example of a popular browser that functions like this.

   

My SMF Mods & Plug-Ins

WebDev

"Either you repeat the same conventional doctrines everybody is saying, or else you say something true, and it will sound like it's from Neptune." - Noam Chomsky

Sir Osis of Liver

Sorry about the title, Kays.  That was a post & run, and didn't check the title before I posted.  Don't see very well, so stuff gets by me if I'm in a rush.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Kays

#5
Hmm, I think we both should of taken a look at upgrade.php first. ::)

From what I can see, there have been no changes to how the attachments table is handled since 2.0. Any image attachments without a mime type gets queried using getimagesize() for the mime type and then the database is updated accordingly. (upgrade_2-0_mysql.sql lines 1269 and on)

Off hand, the only thing I can think of is if the attachments folder was not accessible for some reason then getimagesize() will fail and the database will not be updated with the mime type.

* Kays now wonders why the database he was looking at didn't have the mime type included. ???

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

Sir Osis of Liver

Original problem with this forum was that forum files were backed up using FZ with default transfer settings, so files without extensions were transfered as ascii, apparently corrupting all attachment files with encrypted filenames.  The backup was subsequently uploaded, due to an upgrade problem, and attachments were overwritten.  We tried restoring several backups, but all were FZ downloads and ng, until they finally came up with a cpanel backup that Underdog restored, and was good in all browsers except IE.  He came up with a fix, as described above, and files now work in all browsers.  I suppose it's possible the cpanel backup somehow damaged the files, but seems unlikely it would only affect IE.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Kays

If the screwed up files were in place when upgrade.php was executed, then, getimagesize() will fail and the mime type for those files will not be updated.

So, which files were in place when the forum was upgraded?

If at first you don't succeed, use a bigger hammer. If that fails, read the manual.
My Mods

Sir Osis of Liver

We don't know that.  Upgrade was attempted by others, and attachments were already buggered when we got there.  Best guess is that they lost the attachments in the course of upgrading from 1.1.12 -> 1.1.19, then uploaded the corrupt backup to try to restore them.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Chen Zhen

  My apologies as I never bothered to go into the upgrade package to determine how it set those mime types. I noticed that they were missing from the attachments table after the upgrade & developed a small tool to set them appropriately.

  Prior to this particular response I went back into that persons original (SMF 1.1X) forum files to determine exactly what it was that I did to fix the corrupted image files. I was uncertain as I had tried many things but I have now figured out the proper application to use.

  If you people ever come across someone that has corrupted their image files with what I suspect was the use of ASCII encoding of the files instead of binary. Simply use the WinSCP FTP Platform to copy the attachments directory to another folder. I have tested this several times and it was indeed that application that fixed those files perhaps by correcting the improper ASCII line endings within the image files.  Had I used it prior to the SMF 2.0.X upgrade procedure, the mime type adjustments would have most likely been unnecessary. Although if a similar situation occurs for someone else the tool is available for them to fix that problem.

Regards.

My SMF Mods & Plug-Ins

WebDev

"Either you repeat the same conventional doctrines everybody is saying, or else you say something true, and it will sound like it's from Neptune." - Noam Chomsky

Advertisement: