Last modified: 2006-06-16 02:33:57 UTC
Halló, 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
A deleted image is permanently deleted. It is not possible to restore a deleted image unless "deleted" images are also archived like old images.
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.
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*.
(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.
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.
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 [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.
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 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.
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 function.
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 func.
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 [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.
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.
Applied with further refinements to r14777.
