Page MenuHomePhabricator

Unable to move a corrupt file on commons: [[:commons:File:Нева.jpg]]
Closed, ResolvedPublic


The first revision is missing and I can't delete this revision. Moving the whole file also fails. If it would not be in use, I would try to temporarily delete the whole file and restore only the non-corrupt version. But Commons Delinker is very fast :PНева.jpg

The person requesting the move wanted one of the following new names:

  • File:Neva River and Palace Embankment, 2009-07-24.jpg
  • File:Вид на Неву и Дворцовую наб. с Троицкого моста, 2009-07-24.jpg

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:09 AM
bzimport set Reference to bz34934.
Rillke created this task.Mar 3 2012, 3:27 PM

See also full list of files with empty oi_archive_name (tab-separated, 1864 row)

(select was "select * from oldimage where oi_archive_name=''")

next file that exists but is not shown!Khajuraho_India_-_Lakshman_Temple_-_Sculpture_15.JPG

And here it turns out a real problem of the timestamp based storage:|info&iiprop=size|timestamp|url&iiurlwidth=365&titles=File:%D0%9D%D0%B5%D0%B2%D0%B0.jpg&iilimit=10&format=jsonfm


"timestamp": "2011-09-23T21:32:56Z",
"size": 3352071,
"width": 3072,
"height": 2304,
"thumburl": "https:\/\/\/wikipedia\/commons\/thumb\/archive\/a\/a5\/20110923213256%21%D0%9D%D0%B5%D0%B2%D0%B0.jpg\/365px-%D0%9D%D0%B5%D0%B2%D0%B0.jpg",
"thumbwidth": 365,
"thumbheight": 274,
"url": "https:\/\/\/wikipedia\/commons\/archive\/a\/a5\/20110923213256%21%D0%9D%D0%B5%D0%B2%D0%B0.jpg",
"descriptionurl": "https:\/\/\/wiki\/File:%D0%9D%D0%B5%D0%B2%D0%B0.jpg"


"timestamp": "2011-09-23T21:32:56Z",
"size": 3310009,
"width": 3072,
"height": 2304,
"thumburl": "https:\/\/\/wikipedia\/commons\/thumb\/archive\/a\/a5\/\/365px-%D0%9D%D0%B5%D0%B2%D0%B0.jpg",
"thumbwidth": 365,
"thumbheight": 274,
"url": "https:\/\/\/wikipedia\/commons\/archive\/a\/a5\/",
"descriptionurl": "https:\/\/\/wiki\/File:%D0%9D%D0%B5%D0%B2%D0%B0.jpg"


Yes, the same timestamp -> result:
comment #1

*comment #0 *

aaron added a comment.Apr 19 2012, 8:37 PM

I ran a cleanup script on all orphaned commons files and didn't fix this particular file row. I'll need to see how many empty oi_archive_name rows are left and consider just deleting those rows.

Directly deleting the rows? At least you should keep a backup before...

(In reply to comment #5)

and consider just deleting those rows.

This will lead to inconsistency with OploadLog, is not?

Note what are two difference cases:

Example #1 -Нева.jpg - empty 'oi_archive_name' value

Example #2 (comment #1) - - valid 'oi_archive_name' value, but "File not found" (corrupt file storage)

Moving this down in priority only because Aaron is working on what he believes is the root cause (bug 36132), and I want to move this down below that on his list of stuff to do. With any luck, this will automatically get fixed as a result of that.

aaron added a comment.Apr 20 2012, 7:27 PM

(In reply to comment #6)

Directly deleting the rows? At least you should keep a backup before...

Of course. Though I don't plan on doing that anymore after looking at some of the examples more. It nice to at least see some of the history more clearly (without consulting action=history), so I'd prefer to leave the stub rows.

What can be more easily fixed is just changing the doDBUpdates() function of LocalFileMoveBatch. The line "$status->failCount += $total - $affected;" results in negative values in this case, causing the 'imageinvalidfilename' error.