thumbnail generator fails with a % in file name (update image magik)
Closed, ResolvedPublic

Description

Author: a.d.bergi

Description:
The error report says something about "unable to open image". Imho the % isn't escaped correctly somewhere, could this be fixed please?
I think this error occurs just at jpgs, compare [[commons:file:00%.svg]], [[commons:file:00%.png]].


Version: unspecified
Severity: major
URL: http://upload.wikimedia.org/wikipedia/commons/thumb/3/30/Mundloch_wiki_20%25.JPG/120px-Mundloch_wiki_20%25.JPG
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31079

Details

Reference
bz26233
bzimport set Reference to bz26233.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Dec 4 2010, 3:32 PM
TheDJ added a comment.Dec 4 2010, 10:13 PM

Where are you getting these links from ? If I visit these image pages, all links to their thumbs are correct.

http://upload.wikimedia.org/wikipedia/commons/thumb/3/30/Mundloch_wiki_20%25.JPG/120px-Mundloch_wiki_20%25.JPG is broken for me, and thats directly from the history section of [[commons:file:Mundloch_wiki_20%25.JPG]] (the image is small, so the main image displayed on the image description is not resized).

p.s. correct links for the above mentioned counter-examples are: [[commons:file:00%25.svg]] and [[commons:file:00%25.png]] (since bugzilla isn't as tolerant as wikitext)

Bryan.TongMinh wrote:

cc. Tim Starling; he examined the IM source for r65467, so hopefully he has an idea what is going on.

Is there any test case which has not been destroyed by Commons admins?

There's a bug which causes %% to not work as expected. I've reported it upstream, with a patch:

http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=17810

EN.WP.ST47 wrote:

Since the upstream claims that a release was in 6.6.7-1, and the current version is 6.7.0-8, I can only assume that your patch was applied. I can't tell what version we're running though, and the bug still seems to be present, so tagging this testme.

Point of note in response to comment 0, this also applies to png images in addition to jpg images. The reason 00%.png works is because the image is already tiny and we don't upscale really small images. (SVG's aren't affected since we don't use image magick for them)

I believe we're currently using ImageMagick 6.6.2-6 2011-03-09 Q8 (based on image metadata), which would indicate we need to update to fix this bug. Thus I'm going to remove testme and add ops.

jelle.zijlstra wrote:

*** Bug 30789 has been marked as a duplicate of this bug. ***

brion added a comment.Sep 7 2011, 8:04 PM

Copying from the dupe on bug 30789:

I can confirm that the patch made it in and that 6.6.9 works for me locally; we still have 6.6.2 deployed however, so it's still affecting us in production.

I've filed an RT ticket internally to request that our deployed ImageMagick get
updated: http://rt.wikimedia.org/Ticket/Display.html?id=1444

  • Bug 31092 has been marked as a duplicate of this bug. ***
  • Bug 31079 has been marked as a duplicate of this bug. ***

Just another example. I just report it because the last entry is from 09-2011, about 3 months ago.

https://commons.wikimedia.org/wiki/File:%25_of_U.S._households_connected_by_age.png

Umm, is this still happening? None of the example images in the bug seem to be affected (However, the metadata seems to still indicate the old version of imagemagick in use...)

(In reply to comment #15)

Thumbnails in the history of
https://en.wikipedia.org/wiki/File:Ex_1%25_ample.jpg still don't show up. See
the error at
https://upload.wikimedia.org/wikipedia/en/thumb/d/db/Ex_1%25_ample.jpg/111px-Ex_1%25_ample.jpg
.

Hmm, enwikipedia is still on 1.18, so maybe this magically got fixed somehow in 1.19. Uploading the image to test, and it seems to work https://test.wikipedia.org/wiki/File:Ex_1%25_ample.jpg

Looks like that issue got solved, both [[commons:file:00%.svg]], [[commons:file:00%.png]] give thumbnails.

Gilles moved this task from Untriaged to Done on the Multimedia board.Dec 4 2014, 10:21 AM
Gilles raised the priority of this task from "High" to "Unbreak Now!".
Gilles lowered the priority of this task from "Unbreak Now!" to "Normal".Dec 4 2014, 11:15 AM
Gilles raised the priority of this task from "Normal" to "High".Dec 4 2014, 11:16 AM
Gilles set Security to None.

Add Comment