Starting from Vista/Server 2008 a native symlinking mechanism is supported by Windows (see mklink command). Since we don't plan to support Windows XP/Server 2003 starting from 5.6 this makes MySQL Server implementation of symbolic links for Windows (based on custom .sym files) redundant. Therefore it is a good idea first to deprecate and then remove completely remove code implementing this custom symbolic links. Note that having this custom implementation around is a bad idea not only from code complexity view point, but it also creates performance problems in some scenarios. Note that associated --symbolic-links parameter has a wider meaning as it also controls whether DATA DIRECTORY/INDEX DIRECTORY clauses for MyISAM tables are going to be ignored on Unixes. Thus it is probably a bad idea to changing value of this parameter or deprecating it in the context of this task. We can start by emitting deprecation warning first time when such table in such a .sym-linked database is used. References ========== http://dev.mysql.com/doc/refman/5.6/en/symbolic-links.html#windows-symbolic-links http://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_symbolic-links
Outline of suggested changes ============================ In 5.6: ------- * Emit a deprecation warning to server error log when a table in .sym-linked directory is used first time. Tentative wording: "Symbolic links based on .sym files are deprecated. Please use native Windows symbolic links instead (see MKLINK command)." * Add a test case that will test how symlinks work on Windows. The idea is to create a symlink from data directory to a directory in scratch directory, thus creating symlinked database. Create a table in this database, run a few DML and SELECTs, drop this table. In 5.7: ------- Remove all code implementing symdir support from the server. Effect on backup/restore ======================== * mysqldump/mysql tool combination is unaware about .sym-linked directories but since it uses plain SQL for backup/restore, such directories are handled transparently by it. Contents of .sym-linked databases will be correctly dumped. During restore database will be recreated as normal non-symlinked directory. Implementation of this WL won't change behavior in this case. * MEB is unaware of .sym-linked databases and doesn't care of them (i.e. doesn't support such databases). So removal of .sym-dir support won't change anything for it too. * mysqlhotcopy script is unaware of .sym-linked databases too. So removal of .sym-dir support won't change anything for this tool either. Additional notes ================ MKLINK command requires Administrator privileges (unless system policies are changed). So it might be problematic to use it from the standard test framework of MySQL.
Details ======= In 5.6: ------- Extend unpack_dirname() function to return indication that during upacking directory name, we have opened .sym file and processed our custom symlink. To achieve this do similar change to symdirget() function. Change code in build_table_filename() to emit deprecation warning when unpack_dirname() indicates processing of .sym file first time after server start-up. In 5.7: ------- - Remove USE_SYMDIR macro and all code withing #ifdef USE_SYMDIR . - Replace usage of my_disable_symlinks with my_enable_symlinks to facilitate next step. - Remove my_use_symdir global variable. In places where it is used to check if DATA/INDEX DIRECTORY clause should be supported use my_enable_symlinks instead. Use my_enable_symlinks to store value of --symbolic-links start-up option.