So it sounds like you did: Create file named "foo.xac" Do lots of edits on foo.xac [set 1] Then open file named "foo.2004xxxxxx.xac" (a backup of foo). Do lots of edits on foo.2004xxxxxx.xac [set 2] Then open foo.xac again. Do lots of edits on foo.xac [set 3], which triggers the backup purger and deletes foo.2004xxxxxx.xac, and all of the set 2 edits are now gone.
Except, set 2 of the edits created backup files themselves, which should be named, say "foo.2004xxxxxx.2005xxxxxx.xac". So even when foo.2004xxxxxx.xac gets deleted by the backup purger on foo.xac, you should have lots of backups named foo.2004xxxxxx.2005xxxxxx.xac. But from my read of the functions in question, there is a bug here, and the 2004xxxxxx.2005xxxxxx.xac backups will get deleted erroneously. I will make a fix and submit it upstream. As for the idea that the way backups are done should be improved, that's certainly true, but the solution (which is in the works upstream) is actually to replace the whole backend with a database system that will avoid these kinds of problems entirely. If you set the file retention days in preferences to 0, that has the effect of turning of the backup-pruning function entirely. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
