Last modified: 2014-05-19 22:03:40 UTC
You do not have permission to move this page, for the following reason: The target filename is invalid https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG It is not possible to move/delete the file.
After moving there are some Files broken: https://commons.wikimedia.org/wiki/Commons:Administrators'_noticeboard#Files are broken after moving
Reported by User: https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors/5#Autoreport by AjaxQuickDelete 679533204530 Needless to say: There is mounting problems in the last time.
Created attachment 13240 [details] Where is the file? I tell you -- it's gone! Screenshot of https://commons.wikimedia.org/wiki/File:Station_59_Dittersh%C3%B6he_bei_Dittersdorf_%28Glash%C3%BCtte%29.jpg
https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG I cannot delete the broken version of this file )(or rename the file etc.)
Aaron: As long as this is "fresh", could you take a look at this? For https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG I don't see the thumbnail rendered for the old revision, and clicking that old revision says "404 Not Found - The resource could not be found. Regexp failed to match URI: "/wikipedia/commons/archive/5/59/" ".
Aaron: Could you take a look at this? Or is this lower level?
I had same problem. (see [[commons:User talk:Hym411#Image missing after rename]]). And when I failed,the file name exist,but there was no media file on the name. (It was restored with some tricks.)
I moved 30 or 40 images today, and I saw this "The target file name is invalid" for 5 or 6 times. It was fixed after 3 or 4 refreshes. I wonder if it needs separete bug.
Found another error: When I clicked for Rename, file disappeared. [[commons:File:Islamic_compex_Shakhi_Zinda_-_13.JPG]].
Could someone take a look at this?
Aaron / Bryan: ping?
Aaron / Bryan: Ping - could you take a look at this?
Any updates?
Are all these comments about receiving a "The target file name is invalid", followed by file disappearing, or do some people get different errors, or do sometimes things other than the file disapearing happen. As it stands, the bug report is a bit confusing, possibly including separate issues that should have their own bug(?) Taking a brief look over the code. This error appears to be coming from LocalFileMoveBatch::doDBUpdates in the case it can't update the db. However in the case of that error, its supposed to rollback the db transaction, and bail, all before touching any files on the file system...
Rainer / Revi /Steinsplitter: I'm sorry this report has not received sufficient attention yet. Are there recent examples for this problem?
Are there recent examples for this problem?
No. The community has reported enough examples sine monts. Pls query the db for anormal db entrys. It is techs work to find this issues. They have access to to productiondb. It well known that a lot of such problems (see other mediastoage bugs) are because of the file "broken" backend.
How can an organization with a budget of US$55 million don't fix such a HIG PRIO bug ??
(In reply to Andre Klapper from comment #5) > Aaron: As long as this is "fresh", could you take a look at this? > > For > https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG I > don't see the thumbnail rendered for the old revision, and clicking that old > revision says "404 Not Found - The resource could not be found. > Regexp failed to match URI: "/wikipedia/commons/archive/5/59/" ". I believe the broken old version of the file is caused by (the now fixed) bug 54736 (Since it has mising archive name, exact same timestamp as other version, and was uploaded by upload wizard). I probable conjecture is that the broken nature of this file is preventing other actions to happen to this file, as a safety precaution when the code notices that it cannot succesfully move/delete/etc the file, so it doesn't do anything to prevent the translation of an inconsistent state/unknown state into a further data loss state. Maybe. That's just a guess with no checking or evidence to back it up.
(In reply to Bawolff (Brian Wolff) from comment #19) > (In reply to Andre Klapper from comment #5) > > Aaron: As long as this is "fresh", could you take a look at this? > > > > For > > https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG I > > don't see the thumbnail rendered for the old revision, and clicking that old > > revision says "404 Not Found - The resource could not be found. > > Regexp failed to match URI: "/wikipedia/commons/archive/5/59/" ". > > I believe the broken old version of the file is caused by (the now fixed) > bug 54736 (Since it has mising archive name, exact same timestamp as other > version, and was uploaded by upload wizard). I probable conjecture is that > the broken nature of this file is preventing other actions to happen to this > file, as a safety precaution when the code notices that it cannot > succesfully move/delete/etc the file, so it doesn't do anything to prevent > the translation of an inconsistent state/unknown state into a further data > loss state. Maybe. That's just a guess with no checking or evidence to back > it up. Testing this theory, I tried locally creating a file that would have bad database entries similar to what bug 54736 would cause (via just adding a dummy oldimage entry without an oi_archive_name), to see if moving/deleting is affected. However I could still move/delete my test file just fine. So no go on that. However it could be that either the physical files are messed up, or that different code paths are executed when using swift vs when using normal file system image backend (like my local wiki uses)
For issue of why we have some files with broken history still happening after the other bug fix, I'm splitting that off to bug 65511, so that this bug could just be about inability to move/delete certain files.
