Description:
When opening tables server treats database and table names which start with '/' (on Unix and Windows) or '\' (only on Windows) characters as equal to names with slashes removed. E.g. '//t1' matches 't1' and '\\test_db' matches 'test_db' (on Windows). Although all such names correspond to one disk table they still treated as totally different tables by table definition cache and meta-data locking subsystem. This leads to various curious and potentially harmful effects.
One of consequences of this issue manifested itself as mysqldump.test failure in test case for bug #9358 in tree with patches implementing WL#3726 "DDL locking for all metadata objects". A workaround was added to he test case to circumvent this problem.
How to repeat:
# Script for mysqltest program which demonstrates one of issues
# which manifests itself on Windows
flush tables;
create database test_db;
use test_db;
create table t1(a varchar(30) primary key, b int not null);
# t1 is accessible through both names !
select * from `\\test_db`.t1;
#a b
select * from t1;
#a b
# But SHOW OPEN TABLES and therefore TDC treats those tables as different
show open tables;
#Database Table In_use Name_locked
#\\test_db t1 0 0
#test_db t1 0 0
#mysql general_log 0 0
# DROP DATABASE fails with unexpected error
--error 1010
drop database test_db;
#ERROR HY000: Error dropping database (can't rmdir '.\test_db', errno: 41)
use test;
# Now script which shows that similar (although not exactly the same)
# exists on Linux
flush tables;
create table t1 (i int primary key auto_increment);
# Again table accessible through both names
insert into t1 values ();
select * from `//t1`;
#i
#1
# But for SHOW OPEN TABLES and table cache they are different tables !!!
show open tables;
#Database Table In_use Name_locked
#test //t1 0 0
#mysql general_log 0 0
#test t1 0 0
Suggested fix:
This problem stem from the fact that additional '/' (or '\') characters between directory and file names are ignored by operating system. Although theoretically server should never try to directly create and/or open files with such inconvenient names thanks to table to file name encoding in practice in case of failure to find encoded version of the name it tries unencoded one to achieve compatibility with pre-5.1 versions. This in its results in opening file through such 'queer' names. See open_table_def() function.
One of possible solutions is to avoid this fall-back to unencoded name either completely or at least of names which start from 'queer' characters like '\' and '/' (and may be some other).
