04-07-2020, 08:12 PM
(This post was last modified: 04-07-2020, 08:15 PM by Geoff Bacon.)
@Mike
I suggest you allow the users to specify how many backups they wish to retain. For efficiency, this should be limited to a small number e.g 1-5 (what about 0?). This value probably wants to default to 3.
Rather than appending numbers to the filenames, I would append dates e.g. mobilesheets_auto_backup_yyyy-mm-dd.db (makes it more obvious to the user which one he might like to use) [edit] Although using fixed numbers might make it easier for user using a script to copy the files to other devices [/edit]
When making a backup, scan the backup directory to count the number of existing backups and determine their dates (use the file date stamp rather than anything embedded in the name). This info probably needs to be saved in a small array in case more than one file needs to be deleted e.g. the user has reduced the number of backups to be retained (from 5 to 1 say).
If the number of existing backups is greater or equal to the desired number of backups, delete the oldest backup and repeat this test.
Then create the backup as you do already.
Another alternative would be to just delete the oldest backup each time before creating a new backup. The code that stores the number of backups could ensure that any excess backups are deleted when the value is reduced. However, this means duplicating the deletion logic so it is probably best to keep deletion to the creation process (it also means that backups are retained as long as possible)
I don't know what you do about multiple starts on the same day (or in a short period). These could easily "flush" the automatic backups. Probably not an issue in normal running but could be if the user is experiencing problems and keeps trying to restart MSP. Perhaps best to limit to one automatic backup a day (hopefully, the user will never need them)
You would also need to devise a mechanism so that the user can select which automatic backup he would like to restore. This would also need to allow a choice of another backup if the first ones tried aren't suitable (don't create any more backups until the user is satisfied that the recovery is good - don't want to flush the backups)
Personally, I don't shut my tablet or MSP down so I don't know if taking it out of hibernation would trigger this code (I suspect not). For users like me, you might have to have a mechanism that detects that the program has been running for more than 24 hours and that a backup is due. This backup could be suppressed if the program hadn't been used in this period.
I'm sure I'm teaching you how to suck eggs
Keep safe
Geoff
I suggest you allow the users to specify how many backups they wish to retain. For efficiency, this should be limited to a small number e.g 1-5 (what about 0?). This value probably wants to default to 3.
Rather than appending numbers to the filenames, I would append dates e.g. mobilesheets_auto_backup_yyyy-mm-dd.db (makes it more obvious to the user which one he might like to use) [edit] Although using fixed numbers might make it easier for user using a script to copy the files to other devices [/edit]
When making a backup, scan the backup directory to count the number of existing backups and determine their dates (use the file date stamp rather than anything embedded in the name). This info probably needs to be saved in a small array in case more than one file needs to be deleted e.g. the user has reduced the number of backups to be retained (from 5 to 1 say).
If the number of existing backups is greater or equal to the desired number of backups, delete the oldest backup and repeat this test.
Then create the backup as you do already.
Another alternative would be to just delete the oldest backup each time before creating a new backup. The code that stores the number of backups could ensure that any excess backups are deleted when the value is reduced. However, this means duplicating the deletion logic so it is probably best to keep deletion to the creation process (it also means that backups are retained as long as possible)
I don't know what you do about multiple starts on the same day (or in a short period). These could easily "flush" the automatic backups. Probably not an issue in normal running but could be if the user is experiencing problems and keeps trying to restart MSP. Perhaps best to limit to one automatic backup a day (hopefully, the user will never need them)
You would also need to devise a mechanism so that the user can select which automatic backup he would like to restore. This would also need to allow a choice of another backup if the first ones tried aren't suitable (don't create any more backups until the user is satisfied that the recovery is good - don't want to flush the backups)
Personally, I don't shut my tablet or MSP down so I don't know if taking it out of hibernation would trigger this code (I suspect not). For users like me, you might have to have a mechanism that detects that the program has been running for more than 24 hours and that a backup is due. This backup could be suppressed if the program hadn't been used in this period.
I'm sure I'm teaching you how to suck eggs
Keep safe
Geoff
Samsung Galaxy Tab A6