Last modified: 2012-03-09 16:13:06 UTC
Please see here: http://commons.wikimedia.org/wiki/Commons:Village_pump#.22upload_a_new_version.22_replaces_old_version perm: http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=67949381#.22upload_a_new_version.22_replaces_old_version Looks like a bad bug if the file really got overwritten without a new file version entry
CC'ing aaron, as there is a good chance this is file-backend-rewrite related. To repeat the actual error messages reported on commons when uploading the affected image: First time around: "Could not store file /tmp/phpYIAfCo at mwstore://local-backend/local-public/4/42/Bundesarchiv_Bild_146-1978-043-13,_Erwin_v._Witzleben.jpg." Second time around: Empty oi_archive_name. Database and storage out of sync? Backtrace: #0 /usr/local/apache/common-local/php-1.19/includes/filerepo/file/LocalFile.php(911): LocalFile->recordUpload2('', 'losslessly crop...', false, Array, false, Object(User)) #1 /usr/local/apache/common-local/php-1.19/includes/upload/UploadBase.php(573): LocalFile->upload('/tmp/phpItyZHg', 'losslessly crop...', false, 1, Array, false, Object(User)) #2 /usr/local/apache/common-local/php-1.19/includes/specials/SpecialUpload.php(446): UploadBase->performUpload('losslessly crop...', false, true, Object(User)) #3 /usr/local/apache/common-local/php-1.19/includes/specials/SpecialUpload.php(181): SpecialUpload->processUpload() #4 /usr/local/apache/common-local/php-1.19/includes/SpecialPageFactory.php(476): SpecialUpload->execute(NULL) #5 /usr/local/apache/common-local/php-1.19/includes/Wiki.php(263): SpecialPageFactory::executePath(Object(Title), Object(RequestContext)) #6 /usr/local/apache/common-local/php-1.19/includes/Wiki.php(593): MediaWiki->performRequest() #7 /usr/local/apache/common-local/php-1.19/includes/Wiki.php(503): MediaWiki->main() #8 /usr/local/apache/common-local/php-1.19/index.php(58): MediaWiki->run() #9 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...') #10 {main}
The exception is new. Previously, garbage values would go in the DB. See bug 34934.
Aaron, could you look at replacing the exception with a more friendly error message?
This should stop occurring with r113312. The missing files should still be floating around on NFS. The metadata in the DB row right now for the effected files must be incorrect. This would need to be located and manually fixed. This may warrant a separate shell bug.
(In reply to comment #4) > This should stop occurring with r113312. > > The missing files should still be floating around on NFS. The metadata in the > DB row right now for the effected files must be incorrect. This would need to > be located and manually fixed. This may warrant a separate shell bug. did so: bug 35048
(In reply to comment #4) > This should stop occurring with r113312. Do you know how many files were affected? Or when (which conditions) this happened?
I do not know if this is important: Same error message but different behavior today: File:Bundesarchiv Bild 183-09587-0004, West-Staaken, Ausgabe von Lebensmittelkarten.jpg First attempt failed (error message: "Could not store file /tmp/..."). Second upload worked. Result: Original version still available. First reupload is missing (linking to [http://upload.wikimedia.org/wikipedia/commons/archive/1/1a/] (sic)) Second reupload available. Same here: File:Bundesarchiv Bild 183-1982-0510-014, Meiningen, Maschinenhof des KfL.jpg
(In reply to comment #7) > I do not know if this is important: > > Same error message but different behavior today: > That is the behavior I'd expect when storing the temp file fails (this is how it used to be in 1.18). It's still ugly and should look more atomic, but that will probably cleaned up later.
