Comment 1 for bug 1079700

The reason is that even though we iterate and copy .ibd files based on a "data dictionary snapshot" (actually, a list of tablespaces represented by a fil_system_t structure) taken before starting a backup, we don't validate if the files being copied are consistent with that snapshot.

Consider the following case.

- before taking a backup there are tables t1 and t2 in fil_system.
- after t1 has been copied by xtrabackup, we do RENAME TABLE t1 TO temp, t2 TO t1, temp TO t2;
- xtrabackup then copies t2 (which is in fact the original t1)

As a result, the backup will contain two identical (i.e. with same ID) tables with different names, and the original table t2 will be lost.

I think the only way to guarantee that files being copied are consistent with the snapshot created before starting the backup is to reuse file handles created when populating the list in fil_system_struct, rather than reopen files by their names as we do currently.

However, there's still a possibility of table rotation occurring while fil_system is being populated before the backup. But in this case xtrabackup will fail with an InnoDB error message about duplicate tablespace IDs before copying any files. I.e. at least it will not create a broken backup.