May 23 2020
Commons discussion: https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical
Jul 19 2018
Still happening, FWIW
Jun 15 2018
Jun 10 2018
Now in German, presumably because User:Sänger is the last editor of the page.
May 31 2018
... actually this has disappeared without an intervening edit to the page.
This is currently happening again, this time in Chinese, and the last person who edited has a Chinese username.
May 16 2018
OK... this is no longer happening. I have literally no idea what went on there, but am attaching screenshots of two still-open tabs to verify I haven't gone mad. In the diff, clicking previous diff would show it in English, then clicking next would show it in Polish.
May 11 2018
Nov 28 2016
I would suggest that this is a case where the perfect is the enemy of the good. It would be impossible to defend against a knowledgeable adversary using good steganographic techniques, who is trying to upload an extra ~1% payload. I think it should be relatively easy to prevent ~800MB .iso images and movies, etc. from piggybacking on pretty much any file. On the other hand, it has been pointed out that we can catch a lot of this stuff with AbuseFilters.
Oct 18 2016
All reporters on COM:AN also now report it working.
I can no longer reproduce on any of the files.
The file being served is not corrupt... The sha-256 of the file interpreted as text is: d1a021c6178397fdc59eb4e221c7f7779da2c4ab85d4b7f36ed4f28f231567f8
The IP serving me upload.wikimedia.org is 22.214.171.124
In Firefox 49.0.1 on Windows 7 64-bit: Content-Type: image/jpeg
In Chrome 54.0.2840.59 m on Windows 7 64-bit: content-type:text/html; charset=UTF-8 (though there is also content-encoding:gzip which is not present in Firefox)
Oct 3 2016
I get the same error following the same steps on Firefox 49.0 on 64b linux as well, fwiw, so it's not some weird cookie or cache issue.
Sep 30 2016
Please treat this as a Feature Request to echo back the input text when displaying any Error message.
Jul 6 2016
I don't think it's caused by similarity of names... The following just failed twice:
Jul 4 2016
This is still happening. I don't believe it's due to multiple people trying to delete the files, since the files remain after failure. Possibly relevant: the files where deletion fails universally take a _long_ time to generate the thumbnails, or simply don't generate thumbnails on the File: pages.
May 24 2016
Also happened four or five times on:
May 17 2016
Identical error is happening for https://commons.wikimedia.org/wiki/File:August_Kierspel.jpg
Mar 1 2016
I removed my comment in order to attempt to avoid derailing this bug report, which I have failed to do. Apologies to all for that.
Oct 27 2015
Oct 21 2015
OK... I did try to choose my language carefully, but understood. I also see now that I should have checked the headers before reporting.