Last modified: 2014-09-02 12:23:26 UTC
Created attachment 9063 [details] Recentchanges showing delete entries, but files/pages still exist Noticed on eswikibooks, when trying to batch delete (using deleteBatch.php) all files: Archivo:02265 suciedad 3.jpg Warning: wfMkdirParents: failed to mkdir "/mnt/upload6/private/archive/wikibooks/es/m/6/g" mode 511 in /home/wikipedia/common/php-1.17/includes/GlobalFunctions.php on line 2354 http://es.wikibooks.org/wiki/Archivo:02265_suciedad_3.jpg Not sure if it's just an issue with the deleteBatch, but if it can't delete, the whole thing should abort, and not generate the RC entry
In these cases, it seems it's deleted the page, but the image still exists, and is also a dupe of one on commons
So yeah, if it can't create the archive folders, the whole delete should abort and rollback...
deleteBatch seems to act differently from the UI deletion... Looks like it first deletes the image, then deletes the page. If the file deletion fails, it will print a warning message... but continue on deleting the page anyway. deleteBatch also assumes that failure from File->delete will return something evaluating to false, which seems to match its doc comments... but LocalFile->delete claims it actually returns a status object. So it may be getting a status object saying it's failing, thinking that's success, and then continuing along deleting the pages anyway. So I think what's happening is: * it's failing to delete the files, and doesn't detect that fact * it is deleting the pages regardless of whether the image delete succeeds * the page delete saves a log entry * the link still shows blue instead of red because the file still exists (Note that when deleting through the web UI, you end up going through FileDeleteForm which hits the article first and then the image, IIRC. Eek! It at least attempts to roll back the page deletion, but with all the stuff we have in there these days I don't know if that actually works as expected.) Short fix should be something like: * update doc comment on File->delete to match LocalFile->delete etc * fix deleteBatch (and any other callers of File->delete) to check status objects * change deleteBatch to skip over the page if the image won't delete properly Longer fix probably involves refactoring the delete / doDelete on Article / WikiPage / ImagePage to be more consistent and handle that for us. :)
