Last modified: 2006-06-16 02:33:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2099 - Undeletion of images
Undeletion of images
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal enhancement with 8 votes (vote)
: ---
Assigned To: Brion Vibber
Depends on:
  Show dependency treegraph
Reported: 2005-05-07 07:01 UTC by lɛʁi לערי ריינהארט
Modified: 2006-06-16 02:33 UTC (History)
3 users (show)

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

Work in progress in case I get hit by a bus tomorrow (27.51 KB, patch)
2006-06-13 08:49 UTC, Brion Vibber
Work in progress (35.45 KB, patch)
2006-06-14 00:10 UTC, Brion Vibber
Work in progress (42.51 KB, patch)
2006-06-14 10:19 UTC, Brion Vibber
Work in progress (46.60 KB, patch)
2006-06-14 21:15 UTC, Brion Vibber
Work in progress (47.99 KB, patch)
2006-06-15 09:45 UTC, Brion Vibber
Work in progress (52.86 KB, patch)
2006-06-15 23:39 UTC, Brion Vibber

Description lɛʁi לערי ריינהארט 2005-05-07 07:01:18 UTC

Undeleting an image will resore only the associated page in the image namespace
but not the image itself.

This is quite iritating because the user interface suggests somthing else
compared to what realy happens.

I tested it at [[ro:]] where it did not crash but it crashed on the Nuka-Wiki
which was recenty synchronised with CVS.

Regards Reinhardt
Comment 1 Zhen Lin 2005-05-09 11:48:29 UTC
A deleted image is permanently deleted. It is not possible to restore a deleted
image unless "deleted" images are also archived like old images.
Comment 2 M. Creidieki Crouch 2006-01-16 05:34:33 UTC
I will happily pay a $50 USD bounty to the developer or developers team who
fixes Image Undeletion.  Payable by Paypal, Money Order, or personal check. 
Payable to the individual(s) or to the charitable foundation of their choice.  

Maximum of $50 USD will be paid, though it may be split between multiple
developers; offer expires 01/01/2007, or when this bug is closed under any
resolution.  Woot.
Comment 3 M. Creidieki Crouch 2006-01-16 05:39:10 UTC
After a quick IRC question: I have no idea whether this is a Mediawiki bug or an
en-Wikipedia setup quirk.  My hope is for this to be fixed *on the English
Comment 4 Rob Church 2006-01-16 11:08:34 UTC
(In reply to comment #3)

MediaWiki doesn't store images in quite the same manner as page data; the file
system is used, as opposed to storing them in the database with separate image
and archive tables, etc. Ergo, undeletion is not possible, so this is a problem
with MediaWiki, not a particular configuration.
Comment 5 Michał Buczyński 2006-02-16 23:50:36 UTC
Well, it's even not really a question of MediaWiki but mostly of Foundation's
policy of saving disk quota. In my opinion this policy is wrong as all
Wikiprojects are prone to major acts of vandalism. 

If any user upgrades a media file, the old version is deleted. Well, the way to
do an especially malicious attack is obvious. 
I am afraid that finally vandals will realize this fact and the Foundation will
do something about it just after a massive flood of swapping all the images with
a blank jpg file using a bot happens.

Change of this policy should be a priority but few seem to care what shows a
sheer folly...

Comment 6 Brion Vibber 2006-02-17 00:12:07 UTC
Comment #5 is outright false.
* There is no "policy of saving disk quota".
* It is false that "If any user upgrades a media file, the old version is 
deleted." In fact, the file is retained and archived. It is not removed 
until a sysop deletes it.
Comment 7 Michał Buczyński 2006-02-17 00:16:25 UTC
O.K. self-correction: history of images is saved; wrong info, hyeh.
Sorry for your time. :) 

Some security feature (like one week buffer for deleted images) would be still
helpful though.
Comment 8 Platonides 2006-05-13 21:13:21 UTC
This is being discussed now on commons at

The undelete should simply be available for X time after te deletion (delayed
deletion on filesystem).
Comment 9 Brion Vibber 2006-06-13 02:15:56 UTC
Working on this now...
Comment 10 Brion Vibber 2006-06-13 08:49:42 UTC
Created attachment 1944 [details]
Work in progress in case I get hit by a bus tomorrow

Deleted file can be stored and viewed through special:undelete; needs
restoration function, fallback to clean delete, and a lot of testing.
Comment 11 Brion Vibber 2006-06-14 00:10:01 UTC
Created attachment 1948 [details]
Work in progress

Uses more compact base-36 representation of the SHA-1 hash (32 chars vs 40),
does more validation, now appears to delete old and current versions properly,
allows viewing of file revisions through Special:Undelete when no text
revisions are available.

Next steps: restoration, handier undelete link when no deleted text revisions

The base conversion function may need to be rewritten; I snagged something off
a comment on the base_convert function for initial testing.
Comment 12 Brion Vibber 2006-06-14 10:19:04 UTC
Created attachment 1949 [details]
Work in progress

Basic restoration now works. Needs some more tuning up and testing; display of
undelete link when no text revisions are archived; check base-36 conversion
Comment 13 Brion Vibber 2006-06-14 21:15:41 UTC
Created attachment 1953 [details]
Work in progress

Handles restore of archival version to current. Individual selection now
correct. Undelete link/tab now displays for files as well as text revisions
deleted. Needs more testing, check of logging behavior, check base conversion
Comment 14 Ilmari Karonen 2006-06-14 22:03:25 UTC
Does this patch also fix/workaround Bug 5402?  It seems to me this would be a
good opportunity to get rid of that minor annoyance as well.
Comment 15 Brion Vibber 2006-06-14 22:59:05 UTC
No, but future changes will. This is *not* a good opportunity
to change the entire file structure (unless you want to wait
months instead of days for this); this *does* introduce code
structures which in the future will be used as a basis for
restructuring all images.
Comment 16 Brion Vibber 2006-06-15 09:45:35 UTC
Created attachment 1954 [details]
Work in progress

Rewrote base conversion function from basic output-in-arbitrary-base and long
division algorithms. Pretty much the same as the algorithms are true ;) but it
now validates input data and is maybe a little clearer in how it functions.
Comment 17 Brion Vibber 2006-06-15 23:39:13 UTC
Created attachment 1962 [details]
Work in progress

Seems pretty solid. I do want to try using unique IDs instead of timestamps for
file rows, and then a database updater needs to be added.
Comment 18 Brion Vibber 2006-06-16 02:33:57 UTC
Applied with further refinements to r14777.

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