Last modified: 2014-05-22 16:21:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42737, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40737 - Old deleted versions of a file not moved when a file is moved
Old deleted versions of a file not moved when a file is moved
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.19.0
All All
: Lowest major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-03 06:35 UTC by Capmo
Modified: 2014-05-22 16:21 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Capmo 2012-10-03 06:35:33 UTC
Suppose a file Old.jpg is uploaded to a wiki; then a second version of the file is uploaded with same name. The first file revision is then deleted.

The file is now renamed (moved) to New.jpg: the deleted page history is moved to the new title, but the deleted file itself is not. If I check the page history for Old.jpg, I can see there's a deleted revision and can even undelete it, but then I'll have a file without an associated page (only a 'create' tab is shown, instead of 'edit/delete/history')

I made the same test in MW v1.16 and MW v1.19 and both behaved in the same way.
Comment 1 Alex Monk 2012-10-03 14:54:10 UTC
(In reply to comment #0)
> I made the same test in MW v1.16 and MW v1.19 and both behaved in the same way.

Version -> 1.19.0. 1.16 is unsupported.
Comment 2 Jesús Martínez Novo (Ciencia Al Poder) 2012-10-31 20:20:04 UTC
I don't know if that's supposed to be a bug.

Normal pages have the same behavior, except that when you can't delete a single revision but the entire history (unless a special extension is installed). If you delete a page, then restore some revisions, and then move that page to a new location, only the current revisions are moved. Deleted ones remain at the old title since they are unaffected. The same happens with deleted versions of an image.

I agree that when performing page moves, the logs of the page gets fragmented, so log entries performed to the old page aren't "renamed" to the new page. This affects not only deletion logs, but also protection logs and other that may apply (upload logs, for example). Fixing that hay help to track down those deletions.

Note that if deleted revisions were renamed with the page, there would be no way to do merges or splits of page histories using this way. I don't know if there's an alternative to this currently.
Comment 3 Capmo 2012-11-06 15:27:04 UTC
Jesús, I agree with you that in the case of regular pages it may not be regarded as a bug. That's because a page revision can be considered as an independent entity.

But files work differently: each uploaded file *must* be uniquely associated with a page revision, otherwise the referential integrity is broken. In order to keep the database consistency, the deleted page revisions of a file should then not be moved to the new title (similarly to the example you gave of a regular page), retaining the old title together with their associated deleted files.
Comment 4 Capmo 2012-11-06 15:33:57 UTC
Changed title to a more descriptive one.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links