Description:
When attempting to rename an ARCHIVE table the process fails midway through due to a .ARN
file not existing.

The .ARZ file is successfully changed however the .ARM and .frm are left unchanged and
thus the database breaks.

Specific error returned by the server is:

ERROR 7 (HY000): Error on rename of './abc/blah.ARN' to './abc/whatever.ARN' (Errcode: 2)

How to repeat:
CREATE TABLE `blah` ( `something` varchar(10)) TYPE=ARCHIVE;
RENAME TABLE `blah` TO `whatever`;

Suggested fix:
A check probably needs to be implemented to see if the table is being optimized and not
permit the rename during optimization - this then would avoid a .ARN file needing to be
renamed, or perhaps this is just a simple typo and .ARN should be .ARM?
I havnt looked at the source code so this is just a wild guess.

If the .arn file doesn't currently exist, the behavior should be to silently ignore and do
the rename.  This means that the default rename operation that is based on bas_ext() is
not behaving correctly.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/24303

Added the function ha_archive::rename_table which ignores the error that occurs when
nonexisting .arn file is renamed
Pushed to 4.1.12 and 5.0.6

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/24402

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/24439

Noted in 4.1.12, 5.0.6 changelogs.