Bug #3182 DROP DATABASE fails on RAID directories

• Submitted: 15 Mar 2004 16:31
• Modified: 27 Apr 2004 17:33
• Reporter: Paul DuBois
• Status: Closed
• Category: MySQL Server
• Severity: S3 (Non-critical)
• Version: 4.0, 4.1
• Assigned to: Michael Widenius
• CPU Architecture: Any

[15 Mar 2004 16:31] Paul DuBois

Description:
The manual indicates that DROP DATABASE works as follows:

The `DROP DATABASE' command removes from the given
database directory all files with the following extensions:

*Ext*   *Ext*   *Ext*   *Ext*
.BAK    .DAT    .HSH    .ISD
.ISM    .ISM    .MRG    .MYD
.MYI    .db     .frm

All subdirectories with names that consist of 2 hex digits 00-ff (`RAID'
directories) are also removed.

Unfortunately, that is *too* literally true for RAID directories. It really
does remove only hex-named directories with two digits. This fails
if you create a RAID table using a RAID_CHUNKSIZE value of 257 or
greater. In that case, some of the raid directories have names with
three or more digitst, and DROP DATABASE fails to remove them.

How to repeat:
CREATE DATABASE t;
USE t;
create table t (i int) raid_type = 1 raid_chunks = 257 raid_chunksize = 1;

That will create RAID directories named 00, ..., 100.

Now do this:

DROP DATABASE t;

The server removes the directories 00, ..., ff, but not 100.
That causes the removal of the t database directory to fail,
and the database continues to exist. (By the way, under 4.1,
that failure doesn't generate a warning; should it?)

Suggested fix:
I suppose remove all subdirs with names consisting
entirely of hex digits?

[27 Apr 2004 17:33] Michael Widenius

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

This is now fixed by limiting raid_chunks to be <= 255.

(This was needed anyway as we save the raid_chunks number in only one byte in the .frm file)

Fix will be in 4.0.19 and 4.1.2