lowzl wrote:

A deleted image is permanently deleted. It is not possible to restore a deleted
image unless "deleted" images are also archived like old images.

creidieki+wikibugs wrote:

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.

creidieki+wikibugs wrote:

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
Wikipedia*.

robchur wrote:

(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.

sandbox wrote:

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 #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.

sandbox wrote:

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.

This is being discussed now on commons at
http://commons.wikimedia.org/wiki/Commons:Village_pump#Minimum_requirements_for_voting

The undelete should simply be available for X time after te deletion (delayed
deletion on filesystem).

Working on this now...

Created attachment 1944
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.

attachment 2099-work.diff ignored as obsolete

Created attachment 1948
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
present.

The base conversion function may need to be rewritten; I snagged something off
a php.net comment on the base_convert function for initial testing.

attachment 2099-work2.diff ignored as obsolete

Created attachment 1949
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
function.

attachment 2099-work3.diff ignored as obsolete

Created attachment 1953
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
func.

attachment 2099-work4.diff ignored as obsolete

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.

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.

Created attachment 1954
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.

attachment 2099-work5.diff ignored as obsolete

Created attachment 1962
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.

Attached:

Applied with further refinements to r14777.