TI2010-#6029 Why this message when I go to edit an existing scheduled task: Myxxx(2).tib exists - do you want to overwrite it?

It would be really great if acronis support would jump in on this one.

I find this issue one of the most infuriating things about the archives.xml recovery catalog and TI 2009/TI2010 in general.

The catalog is fragile, it breaks, it always thinks its right even if 100% of all evidence proves its wrong.
Background: In all versions of TI up through and including v11 there was not a catalog such as this. At backup runtime TI would simply inspect the files found in the target folder, accept what it sees as gospel. TI would then proceed to make the appropriate full, or next link in the INCR chain based on what is in the target folder. This was a simple system that was 100% reliable. now granted it also meant that all tib files had to be in the same target folder but for home users that is very much the norm/rule.

Starting in 2009, TI tried to incorporate a recovery catalog. In theory it aught to work, and what might have given them was the ability for you to place your full on one device and an incr on another.
This may be great for some huge IT shop were backups routinely can not fit on a single device but most home users they only have 1 target device, and if they have several target devices they still are very likely to keep all related incr/full files together because if you actually need to perform a restore you need the entire set of files and its much easier to deal with one usb drive than to scramble around and collect 5 or 6 of them to do a restore.

I have personally spoken with at least 6 IT professionals and Aconis users, and 100% of them have experienced the exact same issue as you. The catalog routinely becomes confused.

For the most part, I try to define a backup job once and then never edit it again - ever.
Its ok to right click the job and change the schedule, enable, disable or start but I do not dare edit.
I have even gone so far as being forced to go into the recovery tab, find the existing job and delete them, then with all target .tib files deleted and all recovery catalog deleted/purged edited/recreated the task making sure the every panel is exactly as desired. - and of course re-running the backup.

I use chain2gen and 100% of all my backup chains - regardless of how many generations I have, are always neat orderly sequential file names sets. Anyone can look at the filenames at instantly know those 5 files are a set. Here is an example.
mybackup-.tib
mybackup-2.tib
mybackup-3.tib
mybackup-4.tib
mybackup-5.tib

If you must edit an existing job the PDF for chain2gen includes instructions for how to work around this edit bug.

None of this would have had to occur if the recovery catalog did not exist, or if acronis gave us a button to press to tell the catalog to go refresh itself based on the actual drive/folder contents.

Its worth noting the recovery catalog itself (archive.xml) is not used or needed when performing a restore from a crash. One simply buys a new HD, and perform a restore without ever having needed or used the catalog.

My opinion is archives.xml is a fragile concept, that lacks any interface for users to call it during command line pre/post tasks as well as lacking any interface to have the catalog sync itself with reality (actual folder contents). In summary, the catalog is too short on interface features and too fragile. I think we would be better off if it were disabled with acronis reverting back to its v11 behavior or if acronis put for the programming to make the catalog robust so it operates both as intended and as home-users operate.