This is an interesting issue. Seems that since the beginning of time, PerconaFT changes any run of non alphanumeric characters in a FT file name to a single '_'. When dir-per-db was added, this extended to the database directory name as well. This is not entirely consistent with MySQL behavior. MySQL allows some non alpha numeric characters but maps others to the hex code value of the character.

For example. MySQL allows you to create a database named ':'. That's right, just colon. What gets created on disk is a directory named @003a for the .frm and .opt files. If the table is a TokuDB table and dir-per-db is enabled, the FT layer instead wants to put all of the data files in the database directory named _003a instead. This is all fine and good...until a user tries to rename a table in this directory.

What happens is that as a result of the fix for https://tokutek.atlassian.net/browse/DB-1030 in ha_tokudb::rename, we now make a mysql calll to check_db_dir_existence, which eventually calls build_table_filename. build_table_filename transforms again the '@' character into '@004', so now it ends up looking for a directory named @004003a instead of @003a.

That is the first part of the problem, the second is what DB-1030 was trying to prevent and that is moving a table/file into a directory that doesn't exist. Since we are not making the same transformations of @ to _ up in the TokuDB layer, we aren't even really looking at the right directory to prevent the move, we should be looking for _003a not @003a. This is expected and really as designed as the FT layer will attempt to create the missing directory before placing any files there, but it is still not very accurate.