Comment 10 for bug 782850

This should be at least clearly documented.
A use case where it might interfere is what XBM (https://code.google.com/p/xtrabackup-manager/) calls "continuous Incremental backup" - It creates a seed backup (i.e. full backup) and then keep backup incremental ones.
When the chain reaches a certain size, it will apply the oldest snapshot to the seed, and delete it.

The problem is that XBM has another feature called "materialized copy" where after *each* backup, it applies that *same* snapshot to *another* copy of the seed, therefore always maintaining a prepared backup copy, ready to restore.

The process goes something like this:

1. Create a full backup under /backups/1
2. Create a symlink called /backups/m1 which points to /backups/1
3. Create an incremental backup under /backups/2
4. Copy /backups/1 to /backups/m2, and remove the /backups/m1 symlink
5. Apply /backups/2 to /backups/m2
6. Create an incremental backup under /backups/3
7. Apply /backups/3 to /backups/m2
8. Repeat steps 6 and 7 until you reach the maximum allowed snapshots:
8.1 Apply the oldest snapshot (/backups/2) to the seed ( /backups/1) and delete the snapshot ( /backups/2).

Step 8.1 will produce bad results as /backups/2 was already used in step 5

In my case, it produced an ibdata file of 1.2TB in size, while the actual ibdata file is 180MB ~