Last modified: 2010-05-15 15:37:47 UTC
Images can be uploaded in the form 123px-Something.jpg. This clashes with the new structure of the thumbnail directory in 1.5. If a thumbnail of 123px-Something.jpg is requested, the script attempts to create a directory called 123px-Something.jpg, but that name may already be taken by an actual thumbnail image left after 1.4 conversion. Thus, warnings and broken thumbnail links are issued on render.
Really it's only a conversion issue, the problem can be solved by moving all offending images to the new structure.
I am currently loading the DB dump of en: into a MySQL installation. I will search for such titles (LIKE '%px-%' should be sufficient).
*** Bug 2763 has been marked as a duplicate of this bug. ***
*** Bug 3055 has been marked as a duplicate of this bug. ***
The problem should be solved by removing all old thumbnails alltogether (delete images/thumbs with everything below). Preferably during the update procedure. As the file name generation procedure is still in flux, most existing thumbnails will be unfindable, so all they do is to take up space and make Tim Starling's life miserable.
(In reply to comment #5) > The problem should be solved by removing all old thumbnails alltogether Yeah, cool idea from me. Unless you do this yourself and find out that I forgot to mention that you'll need to expire all page caches! Otherwise, the caches pages will still try to access the (now gone) thumbnails. The thumbnails only get regenerated when the referring page is rendered from wikicode, NOT when it's just served from some cache!
The workaround is to just request the offending thumbnail of [[Image:Something.jpg]], which will trigger migration of image into the new directory structure, and thus out of the way. In the original example, that means previewing a page containing [[Image:Something.jpg|123px]].
*** Bug 3457 has been marked as a duplicate of this bug. ***
I'd recommend simply changing the thumbnail directory names; naming directories literally for the files feels rather too fragile, and as we see above does not lend itself to a smooth transition due to the name conflicts. If we change the directory layout in a non-conflicting way and leave the existing files, things will naturally fill in without a requirement to pre-purge everything.
(In reply to comment #7) > The workaround is to just request the offending thumbnail of > [[Image:Something.jpg]], which will trigger migration of image into the new > directory structure, and thus out of the way. In the original example, that > means previewing a page containing [[Image:Something.jpg|123px]]. That doesn't seem to work. See http://commons.wikimedia.org/wiki/Image:Alpine_ibex.jpg. If you have your preferences set to display images at 800x600px, the page tries to display the 399x600px thumbnail, but fails with error 403 (Forbidden).
http://commons.wikimedia.org/wiki/Category:CopyrightByWikimedia contains more of these titles. Posted a note at http://commons.wikimedia.org/wiki/Category_talk:CopyrightByWikimedia#bugzilla:02532 == ... [[commons:Category_talk:CopyrightByWikimedia#bugzilla:02532]] [[w:commons:Category_talk:CopyrightByWikimedia#bugzilla:02532]] [[meta:commons:Category_talk:CopyrightByWikimedia#bugzilla:02532]]
Restored bug from flood attack.
This should be fixed in 1.5.7. The problem was buggy migration, not the need for migration.
*** Bug 3069 has been marked as a duplicate of this bug. ***
Fixing the summary...
*** Bug 4722 has been marked as a duplicate of this bug. ***
changing url from http://commons.wikimedia.org/wiki/Category:Unknown to http://commons.wikimedia.org/wiki/Category:Images_uploaded_at_reduced_resolution
