Description:
if you try to rename a partitioned table, and a filesystem error occors during creation of
the 2nd (or nay later) of the MYD/MYI files for the partition, then reanme table will
leave some renamed and some not renamed files. => table is unusable

assuming table t1 partition p1, p2.
- rename t1 to t2
- rename table does t1#p1 => t2#p1 successfull
- rename table fails on  t1#p2 =>  t2#p2

the first rename is not undone, the table is now corrupt

---
The how to repeat mayonly work on certain systems, it relies on the filesystem giving an
error if a filename is to long (since mysql encodes a dot in a filename to @002e this
filename will be very long.)

I have chosen the length in a way that the filename is small enough to create a partition
with a short name, but to long to create a partition with a long name (2nd partition)
It is possible that the required lengt differes on other systems.

I have only teste this on FreeBSD.

How to repeat:
drop table   t1;
create table t1
 (a int)
PARTITION BY RANGE (a) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1xxxxxxxxxx VALUES LESS THAN (11)
);

rename table t1 to `.................................................`;

filesystem before rename
-rw-rw----   1 martin  martin     0 Jul 27 15:58 t1#P#p0.MYD
-rw-rw----   1 martin  martin  1024 Jul 27 15:58 t1#P#p0.MYI
-rw-rw----   1 martin  martin     0 Jul 27 15:58 t1#P#p1xxxxxxxxxx.MYD
-rw-rw----   1 martin  martin  1024 Jul 27 15:58 t1#P#p1xxxxxxxxxx.MYI
-rw-rw----   1 martin  martin  8554 Jul 27 15:58 t1.frm
-rw-rw----   1 martin  martin    36 Jul 27 15:58 t1.par

filesystem after rename
-rw-rw----   1 martin  martin     0 Jul 27 15:58
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e#P#p0.MYD
-rw-rw----   1 martin  martin  1024 Jul 27 15:58
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e
@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e@002e#P#p0.MYI
-rw-rw----   1 martin  martin     0 Jul 27 15:58 t1#P#p1xxxxxxxxxx.MYD
-rw-rw----   1 martin  martin  1024 Jul 27 15:58 t1#P#p1xxxxxxxxxx.MYI
-rw-rw----   1 martin  martin  8554 Jul 27 15:58 t1.frm
-rw-rw----   1 martin  martin    36 Jul 27 15:58 t1.par

Suggested fix:
 undo any renamed files, if an error occurs

trying to drop the table may lead to a server crash. The crash could be realted to  Bug
#29322 or Bug #28490

Thank you for the bug report. Verified as described on FC 6.0.

The comment in the bug is correct that this can be fixed by
creating a rollback case in the routine del_ren_cre_table.
This routine handles failures of create table correctly. It
treats errors at rename and delete differently, in this
case it tries to continue with the rename and delete. For
delete this seems ok, since the user has asked to delete
the table we should remove as much as possible since it
isn't possible to restore deleted files.

For rename we can simply rename in reverse order where it was successful
and do that as soon as we find an error. We do however need to
integrate handler::rename_table into this as well. This routine should
also clean up after itself in error cases, so the problem can occur also
for non-partitioned tables.

So solution is:
1) Make handler::rename_table atomic
2) Integrate handler::rename_table into del_ren_cre_table
3) Make del_ren_cre_table rollback rename operation if
unsuccessful with any rename operation (this also makes
del_ren_cre_table atomic for renames as it is now for
creates)
4) Try to delete as many files as possible in handler::delete_table
Currently it stops deleting if it hits an error.
5) Handle delete case when nothing still was deleted as a special case,
such that we stop immediately in case of no permission for operation.
6) Switch order of call to delete_table and del_ren_cre_table to ensure
that we don't run into problems by removing partition files before we're
sure we can remove the frm file.

See bug: http://bugs.mysql.com/bug.php?id=41272.

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/commits/62053

2742 Mattias Jonsson	2008-12-19
      Bug#30102: Rename table does corrupt tables with partition files on failure
      
      Problem was that a failing rename just left the partitions at the state
      it was at the failure
      
      Solution was to try to revert the started rename if a failure occured.

I will fix the delete code path to work as following:
If the first file to delete fails, then return directly.
If the first file was deleted, then continue and delete as much as possible.

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/commits/62429

2742 Mattias Jonsson	2008-12-29
      Bug#30102: Rename table does corrupt tables with partition files on failure
      
      Problem was that a failing rename just left the partitions at the state
      it was at the failure.
      
      Solution was to try to revert the started rename if a failure occured.