OK, libarchive doesn't strip leading slashes from path names, but that's irrelevant, because xtrabackup strips all directories (including the leading slash) from ibdata1 before passing it to libarchive. So, for example, "/mysql/data/ibdata1" will be stored in the resulting stream with the path "ibdata1".
That will be prepared correctly, because even though innodb_data_file_path stored in backup-my.cnf will contain an absolute path, xtrabackup will strip the directory part from it before executing --prepare (see innodb_init_param()).
However, innobase --copy-back will fail to copy ibdata1 to an absolute path location. I could not test it, because there's a separate issue, see bug #1049291, but from code audit in copy_back() it looks like it would test if the file "<backup_directory>/mysql/data/ibdata1", which of course does not exist, and fail with an error.
Let's keep this report to track that problem. I have also updated the summary accordingly.
OK, libarchive doesn't strip leading slashes from path names, but that's irrelevant, because xtrabackup strips all directories (including the leading slash) from ibdata1 before passing it to libarchive. So, for example, "/mysql/ data/ibdata1" will be stored in the resulting stream with the path "ibdata1".
That will be prepared correctly, because even though innodb_ data_file_ path stored in backup-my.cnf will contain an absolute path, xtrabackup will strip the directory part from it before executing --prepare (see innodb_ init_param( )).
However, innobase --copy-back will fail to copy ibdata1 to an absolute path location. I could not test it, because there's a separate issue, see bug #1049291, but from code audit in copy_back() it looks like it would test if the file "<backup_ directory> /mysql/ data/ibdata1" , which of course does not exist, and fail with an error.
Let's keep this report to track that problem. I have also updated the summary accordingly.