On 2 Dec 2020, at 02:15, Adam Richards <adamjmrichards@...> wrote:



The message's purpose was to explain any slight pause due to the file being written out as a checkpoint.  It would be a "blip" for small layouts, I expect. I can't comment on whether it should show up now, but it was always informational and not an error. 

The reason you may be seeing it is that we have changed the way the checkpoint/autosave code works to retain more information (and your layout) should we suffer a crash or even if you did something "bad". Previously the checkpoint frequency was a balance between being very current and losing the history at restart. And once you accepted the last checkpoint on start, the file was in immediate danger of being overwritten even if you realized it was not what you wanted. If you set a long checkpoint, you would usually go "back in time" after a crash and lose your work.  But if you set it short, all history was lost very quickly. And there was no auto-save, so you had to definitively remember to save, especially if you chose not to use the checkpoint.

Now we have checkpoints that create a rotating set of saved files (every x updates) and auto-save that periodically (every y checkpoints) auto-saves the file. There are two frequencies, one is how many edits you make between a checkpoint, and the other is how many checkpoints before an auto-save.  A zero in auto-save disables that feature but does not stop the checkpoints. On restart, you have the option of using the last checkpoint and continuing to edit, using it but resetting the filename so as not to overwrite the old file, or just using the last save instead.

Because a checkpoint is essentially a .xtc file, we can use the checkpoints to recover several earlier points in time, if we need to. 

All this means is that checkpoints will usually be written more often (unless you disable them).  

Adam