MySQL Bugs: #3877: DROP DATABASE does not remove db.opt file

Bug #3877	DROP DATABASE does not remove db.opt file
Submitted:	24 May 2004 19:26	Modified:	24 May 2004 22:02
Reporter:	Matthew Costello	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	4.1.1-alpha	OS:	Linux (Linux 2.6 (FC2))
Assigned to:		CPU Architecture:	Any

Description:
Doing a "DROP DATABASE dbname" does not remove the db.opt file and does not remove the directory either. Because the directory is still there MySQL thinks that the database has not been removed and a subsequent "CREATE DATABASE dbname ..." fails. There are no error messages in any of the logs.

This fails on a 2xPIII running Fedora Core 2 with the pre-packaged MySQL:

Name : MySQL-server Relocations: (not relocatable)
Version : 4.1.1 Vendor: MySQL AB
Release : 1 Build Date: Mon 08 Dec 2003 04:06:52 AM PST
Install Date: Sat 22 May 2004 07:44:52 PM PDT Build Host: build.mysql.com
Group : Applications/Databases Source RPM: MySQL-4.1.1-1.src.rpm
Size : 31823965 License: GPL
Signature : DSA/SHA1, Mon 08 Dec 2003 03:57:56 PM PST, Key ID 8c718d3b5072e1f5Packager : Lenz Grimmer <build@mysql.com>

But it works using Red Hat 9 and a 2.4 kernel. I have no idea why it would work on one and fail on another, unless the source tarball does not match the pre-built binary. FC2 does have SELinux, but it is disabled. The mode of the /var/lib/mysql directory is 775 and the mode of the /var/lib/mysql/testdb directory is 700; both are owned by mysql:mysql.

How to repeat:
Run the following commands on a FC2 machine. The second CREATE will fail.

CREATE DATABASE testdb CHARACTER SET utf8;
DROP DATABASE IF EXISTS testdb;
CREATE DATABASE testdb CHARACTER SET utf8;

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.mysql.com/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.

Additional info:

I failed to reproduce this behaviour with both 4.1.1-alpha installed from MySQL-server-4.1.1-1.i386.rpm and 4.1 from current source tree (ChangeSet@1.1863, 2004-05-22 23:41:58+04:00) on FC2

Thank you for your bug report. This issue has already been fixed
in the latest released version of that product, which you can download at 
http://www.mysql.com/downloads/

Additional info:

I see you are using kernel 2.6, so it's likely to be this bug (already fixed in 4.0.20, fixed in to-be-released 4.1.2): from the changelog
"Fixed a problem with non-working @code{DROP DATABASE} on some configurations
(in particular, Linux 2.6.5 with ext3 are known to expose this bug).
(Bug #3594)"
http://bugs.mysql.com/3594