In testing this, I noticed something else I hadn't expected: The most recent backup has the largest number. That is to say; .fcstd1 is older than .fcstd2; I can think of reasons it was implemented like this, but I find it odd from a user perspective. I might be alone in that though.
From developer's point of view it makes sense as you can consider it as a revision number of a VCS. But in fact the reality is a bit different and the creation of backup files follows this strategy:
- create backup files with incremented numbers
- once the limit of backup files is reached it searches for the oldest files and overwrites it. So, you can end up with backup files where the latest version has the suffix 1 and the second latest the suffix 10.
So, after all the only relevant information is the creation date and not the suffix number. The whole point of doing it this way is efficiency and reliability because this approach never has to rename an existing file. Following your approach at some point you have to rename all existing backup files in order to keep suffix name consistent with creation date but then reliability sinks dramatically.
Assuming the probability of a successful renaming of a backup file is 99% then the chance that renaming 10 backup files still succeeds is only around 90% (=0.99^10). And this is not just hypothetical because in practise it can happen quite easily to make renaming a file fail, e.g. when any other process like a virus scanner accesses the file.
Also, it turns out that FreeCAD can't open its own backup files. That seems broken too. I have to rename the file to open it.
This is done on purpose. The whole point of a backup is that you can switch back to a certain version at any time (at least for a certain time frame) and therefore it shouldn't happen that you overwrite it by accident just because you loaded it directly into FreeCAD, did some changes and pressed the Save button.
Forcing the user to rename a file gives him the chance to think about what he is doing and if the file is really important that he makes a real backup file and saves it to an external location.
I like this idea. Not for the reasons in the issue, but because I'd like to be able to exclude a specific folder from by normal backup routine; there is no way to de-duplicate a compressed file.
Separating backup from normal files basically means that there can only be a single directory where backup files should go to. But this makes the whole concept of backup files useless as it leads to a massive loss of data.
Example:
You save a project in directory A which then puts the backup files to directory B. At a later point you create a new project which (by accident or on purpose) has the same name as in A and save it to directory C. So, this way you may lose the backup file corresponding to the project in directory A.
Summary:
I partially agree on point 1 and 4 of your proposal but highly disagree on the rest. The rollback function, however, should guarantee not to directly overwrite the backup file.