Last modified: 2006-07-12 02:06:16 UTC
Use case: 0) Wiki is a fresh SVN checkout. 1) User has privs to use Special:Lockdb 2) User goes to SpecialLockdb (e.g. http://192.168.0.64/wiki/index.php?title=Special:Lockdb ) 3) A reason is entered, and the confirmation checkbox is ticked, and the "Lock Database" button is clicked. For me with error_reporting(E_ALL) enabled, and have a fresh SVN checkout, the result is a HTML page containing this PHP warning: ================================= <b>Warning</b>: fopen(/var/www/hosts/mediawiki/phase3/upload/lock_yBgMBwiR) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: No such file or directory in <b>/var/www/hosts/mediawiki/phase3/includes/SpecialLockdb.php</b> on line <b>95</b><br /> ================================= and page that says : ================================= Internal error Could not find file "/var/www/hosts/mediawiki/phase3/upload/lock_yBgMBwiR". ================================= I know that this isn't the most user-facing bit of code, but nevertheless, could we maybe please add in something like this code from Special:Upload before writing to this file: ================================== /** Check if the image directory is writeable, this is a common mistake */ if ( !is_writeable( $wgUploadDirectory ) ) { $wgOut->addWikiText( wfMsg( 'upload_directory_read_only', $wgUploadDirectory ) ); return; } ================================== Also is it possible to perhaps create the default "wgUploadDirectory" (usually "wiki/upload") during installation? (assuming this isn't already being done)
Addressed in SVN trunk, r15490. Er, the default is wiki/images, no? And that's checked out with the rest of the code. If it's not, then creating the default would require write permissions on the directory's parent, which may not be forthcoming, or wise.
> Addressed in SVN trunk, r15490. Thank you! > Er, the default is wiki/images, no? Yes, but it's set to an invalid value (wiki/upload) before that, which proprogates through to $wgReadOnlyFile, which causes the request to be for "upload/lock_yBgMBwiR" However, rather than muddy the waters between this and that (since they're really two different things), to keep it separate I've logged it as Bug 6639 and explained what I think the problem is - but if I've made a mistake in my assumptions in that other bug please feel free to close it and mark it as "INVALID: stupid user error" ;-)
