Page MenuHomePhabricator

"The target filename is invalid" when trying to move/delete specific file on Commons
Open, MediumPublic

Description

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.


Version: wmf-deployment
Severity: critical
URL: https://commons.wikimedia.org/wiki/File:Rue_G%C3%A9n%C3%A9ral-Nouvion.JPG

Details

Reference
bz53770

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:51 AM
bzimport set Reference to bz53770.
bzimport added a subscriber: Unknown Object (MLST).

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.

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 - could you take a look at this?

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.

Aklapper lowered the priority of this task from High to Medium.Nov 8 2020, 11:10 AM