Page MenuHomePhabricator

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


I have a report from a user thaténis_1.JPG and 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: a Fénis 2.JPG, .

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

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



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:57 AM
bzimport added a project: UploadWizard.
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 updated the task description. (Show Details)Dec 5 2015, 9:22 AM
Nemo_bis set Security to None.
MarkTraceur removed MarkTraceur as the assignee of this task.Mar 18 2020, 4:45 PM
MarkTraceur added a subscriber: MarkTraceur.
Aklapper changed the task status from Open to Stalled.Jul 16 2020, 8:51 AM
Aklapper lowered the priority of this task from Medium to Low.
Aklapper updated the task description. (Show Details)
Aklapper removed a subscriber: wikibugs-l-list.

No clear steps to reproduce and five years ago, hence lowering and stalling.