Error uploading style

[CyberAlien]

Something is wrong with style upload process. It messed up contents of several files.

Files relevant to this ticket:
File #1: download zip file
File #2: download zip file

I've installed style in file #1, SMF messed up contents during upload, resulting on what you see in file #2.

Conditions:

• Directory "Themes" is writable (apache user is the same as owner of directory, so php has write permissions to whole home directory)
  
• Some server data: Apache/2.2.20 (Unix) DAV/2 PHP/5.3.8
  
• mySQL 5.1.44
  
• SMF 2.0.2, fresh install without any mods/styles

Steps to reproduce bug:
1. Log into forum, click "Admin" link
2. Click "themes and layout" link
3. In "install a new style" section in file field upload file #1 (see files above)
4. Submit form. Directory "Themes" is writable, so SMF will upload and install file without FTP.
5. Go to Themes/smf_style/, check contents of files that SMF has uploaded. I've packed them in file #2 (see files above)

Files that were messed up by SMF during upload:

• images/admin/current_theme.gif
  
• images/admin/paid.gif
  
• images/buttons/merge.gif
  
• images/buttons/split.gif
  
• images/openid.gif
  
• images/stats_history.gif
  
• images/topic/veryhot_post.gif
  
• images/useron.gif
  

You can compare both zip files to see how files were messed up or repeat that style upload process and see for yourself.

[Illori]

those files appear to install just fine, but they are somewhat corrupted

"windows photo viewer can't open this picture because the file appears to be damaged, corrupted, or is too large."

that is for each and every image you say does not install correctly. this does not happen on other themes, so it is not an smf bug.

[CyberAlien]

What do you mean "not bug in smf"? If you unpack zip file, all images are correct. If SMF unpacks zip file, images are corrupted. Its a bug in SMF.

Unpack file #1, check files. Then install that zip file, and check files on forum. Files get corrupted somewhere during installation.

[Illori]

the theme installer does not modify the images all it does is unpack the zip. if this was an smf bug it would have been reported before. MANY users have installed themes off the theme site with no problems including these images that you report have issues.

[CyberAlien]

It doesn't happen to all themes. Seems to happen to that particular zip file. Maybe there is some bug in zip class that causes it.

[Illori]

i really doubt it as no one else in all the years that 2.0 has been in development has reported the issue, and if so it would have been fixed.

[CyberAlien]

Also, if you'll take a look at this thread, you'll notice people complaining about this quite often.

I was unable to replicate bug until now because I didn't have full information, that is I was only testing download of zip file, noticed that it was correct, but didn't test the installation.

[Illori]

right so it is only happening with the zip that is generated with your script, so maybe the issue is more on your side then ours. you know how many themes have been approved on the theme site that dont have this issue? hundreds.

[CyberAlien]

right so it is only happening with the zip that is generated with your script, so maybe the issue is more on your side then ours. you know how many themes have been approved on the theme site that dont have this issue? hundreds.

There are hundreds of downloads of phpBB styles every day, nobody ever complained. Only SMF users are complaining. I'm using PclZip class to compress zip files, which is very reliable.

I've yet to see software that cannot unpack those zip files correctly.

[Arantor]

If the file is valid before it goes through SMF and it unpacks incorrectly, how is that not an SMF problem?

There are multiple ways to compress a zip, my guess the problem is that SMF doesn't knw properly how to unpack all of them, only certain types.

[Illori]

if i zip your files with the windows compression utility, and install that with the theme installer, no images are corrupted.

[CyberAlien]

It is probably using different compression methods. That doesn't mean that unpacking is correct in SMF. There is a bug with some unpacking method in it.

[IchBin™]

I've seen plenty of issues when it comes to zip programs that add in extra meta data that causes PHP zip functions to not be able to uncompress them properly.

ETA:
For instance I've never been able to get the zip util included in CentOS to work on a theme or mod. It makes all the files corrupted for me when I install a theme.

From my vague memory, SMF uses the built in functions in PHP to uncompress the files. So probably not so much a SMF thing as it is a PHP problem with uncompressing these files.

[Arantor]

The Windows compression utility has been known to cause problems for YEARS. I remember issues back in 2009 for it but I thought they'd been fixed.

7zip is known to play nice, WinRar sometimes throws a wobbler. But it seems that more work needs to be done.

[Antechinus]

images/admin/current_theme.gif
    images/admin/paid.gif
    images/buttons/merge.gif
    images/buttons/split.gif
    images/openid.gif
    images/stats_history.gif
    images/topic/veryhot_post.gif
    images/useron.gif

There are a lot of gifs and other images in SMF. If the problem was related to unpacking zipped gifs then I would expect it to affect all gifs. If it only affects these specific ones, and does so consistently, that would seem to indicate that the problem is with those specific images.

[CyberAlien]

From my vague memory, SMF uses the built in functions in PHP to uncompress the files. So probably not so much a SMF thing as it is a PHP problem with uncompressing these files.

Not exactly. Function read_zip_data in Sources/Subs-Package.php is parsing it and uses gzinflate to unpack chunks of data, same as PclZip, but PclZip does unpack it correctly using same PHP functions.

[CyberAlien]

Found it!

This if() in Sources/Subs-Package.php is causing this error:

Code Select Expand

// Only inflate it if we need to ;).
if ($file_info['compressed_size'] != $file_info['size'])
$file_info['data'] = @gzinflate($file_info['data']);

If if() is removed and data is parsed with gzinflate(), images are correct.

[Spuds]

Thanks for the report and for sticking with it 

Indeed that logic fails, in this case those gif files were so small to begin with that the compressed size ended up being the same as the inflated size but they were still "compressed".

There are some proposed updates for 2.1 in that code, part of that pulls the compression_method that is stored with the local file headers in the archive, we can just use that value to see if the file is reported as stored or compressed to avoid that logic in the future.

[Antechinus]

Aha. Nice catch. So it was related to image size. The odd thing though is that there are quite a few gifs in the theme that are smaller than the gifs that caused problems, yet still unzipped as they should.

[Spuds]

Must just be related to how compressed the gif can be ... perhaps fewer colors in the color palette allows the gif image format to be optimized enough such that deflate can't do better.  I can't imaging that this has not  happened plenty of times before but was likely chalked up to one of those ftp or file glitches.

When I looked at those files in the archive were the same size compressed or not but the zip headers for them showed they were compressed and not stored, as such the program should have acted accordingly.