Andrea,
That would be good to update Section 4.4.3 which currently discusses backup.xml, backup_prev, and perpetual sessions to add additional information about "Autosave continuous backups". Unless I made a mistake, the following are some corrections.
if I don't enable the new option (default), a backup is created at each editing action
True. This is the backup.xml file. When you "Load backup" or "Save backup", this is the file that is written or loaded.
but this overwrites the previous backup.prev
No, before backup.xml is rewritten because of a new editing operation, its current contents is written to backup_prev.
so in .bcast5
there will be only one backup file (plus backup.xml whose function I
don't understand).
So from the above, it should be clear that there are always 2 backups - backup.xml and backup_prev. Of course, if you are a new user, neither of these files will exist until some editing has been done or saved.
If I enable "Autosaves continuous backups" the backup.prev file is not
overwritten, but a new backup.prev_xxxxxxxx_xxxxxx (with data and
clock time) is created.
No. backup.xml and backup_prev work exactly as before. The new ability is that before backup_prev is written over from backup.xml, it is copied to a whole new file named backup_prev.timestamp.
These are small files so their number is not a
problem. In any case when you exit CinGG the various backups are
deleted except for the last 50, which will still be available at the
next restart.
True, but remember, backup.xml and backup_prev are never deleted by the program.
The new option is put in Settings --> Preferences -->
Appearance Tab under the Dangerous section because if you have a crash
or anyway you don't exit CinGG correctly, the delete phase doesn't
happen and the risk is the increase of the backup files inside .bcast5
but, as said, their size is very small and so not a big problem.
With this option enabled, how does File --> save/load backup work?
Is there anything I didn't understand? Is there anything to add?
With the above explanations, I think it is clearer but maybe someone else has something to add. I still think it is necessary to stress the possibility of filling up the disk -- the risk is very low but if the backup file goes crazy and is looped out for some reason, than the possibility exists.
There are a few parts where save_backup() is called (Reuss Andràs):
cinelerra/cwindowgui.C:2
cinelerra/swindow.C:1
cinelerra/keyframepopup.C:2
cinelerra/pluginpopup.C:1
cinelerra/mwindowedit.C:87
cinelerra/presetsgui.C.sav1:1
cinelerra/assetpopup.C:1
cinelerra/cwindowtool.C:1
cinelerra/render.C:1
cinelerra/setformat.C:1
cinelerra/mwindow.C:9
cinelerra/keyframegui.C:2
cinelerra/mwindowgui.C:1
cinelerra/mainmenu.C:1
cinelerra/loadfile.C:2
cinelerra/savefile.C:2
cinelerra/menueffects.C:1
cinelerra/main.C:1
cinelerra/presetsgui.C.sav:1
cinelerra/record.C:1
cinelerra/plugindialog.C:1
Andras knows a lot more about the program calls then I ever will so his lists makes sense as these sound like editing changes.