Reupload/overwriting of old version of a file fails, multiple files are uploaded under same title, old revisions are lost
Open, NormalPublic


I have a report from a user that [[commons:File:Chiesetta_a_Fénis_1.JPG]] and [[commons:File:Castello_Jocteau_5.JPG]] were actually two images each (for unknown reasons), but uploading a reverted (non-current) version under a new title failed, presumably being considered a reupload/duplicate by unauthorised user.
When I tried with the UW I got an unknown error in the first step but normal upload worked: [[commons:File:Chiesetta a Fénis 2.JPG]], [[commons:File:Castello_Jocteau_7.JPG]].

Note that reverting the file to the first version resulted in the first file in file history being lost: related to bug 39615 comment 5? Another byproduct of bug 39221?

In summary:

  1. Upload two files A and B
  2. Expect they are uploaded as files A and B
  3. Find that A is uploaded as A, then B is uploaded with A's title (as a new version)
  4. Try to upload A under a non-A title (or B with its own title after reverting A's title to A file)
  5. Find that you can't upload the file, or history gets lost in the process, or both

Version: master
Severity: major


bzimport set Reference to bz40304.
bzimport added a subscriber: Unknown Object (MLST).
Nemo_bis created this task.Sep 17 2012, 5:46 PM

I tried the following locally but couldn't reproduce the bug.

Upload Penguins1.jpg, now upload Penguins2.jpg as a new version (under the same file name). Then tried to upload Penguins1.jpg again using UW.. it gave no error except 'title exists' (expected) .. after changing the title upload worked.

Am I doing something wrong?

Also didn't lose any file on reverting..

I don't know, maybe when the two files were saved by UW under the same title another mistake was that the saved hash for the file was the one of the older version? But then why would the normal upload work, does UW have additional checks?

If this works under normal conditions, I guess we can lower priority: the original error (uploading two files in one) was probably only WMF's Swift weirdness.

I don't think so, but I am not really sure. I think we should lower priority and come back to this only with pure reproducible ways.
Also marking as Unconfirmed as it worked for me.

I'm sorry for the confusing bug report but the issue is quite confusing in itself. I'm adding all the three different issues in the bug summary and raising severity; bug 54776 suggests this may be causing a few hundreds lost files per month.

Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:40 PM
Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptSep 4 2015, 6:40 PM
MarkTraceur closed this task as "Declined".Dec 3 2015, 6:04 PM
MarkTraceur claimed this task.

I can only barely follow the description of this bug, but I'm pretty sure it's what we call "expected behaviour", at least for now, and at least for UploadWizard. That said, I don't understand what happened here. So I guess we've learned not to do this again.

Nemo_bis reopened this task as "Open".Dec 5 2015, 9:19 AM

No, it's definitely not expected.

Nemo_bis edited the task description. (Show Details)Dec 5 2015, 9:22 AM
Nemo_bis set Security to None.

Add Comment