From this posting:
So here's what I'm thinking of doing. Tell me how this sounds to you. (I have my own opinions about some of the discussion points, but I'm not going to voice them until there's been some discussion.)Full Bleed wrote:I'd like to see granular control of the "Backup" feature in MT. That is, allow users to 1) set how often and 2) how many backups of their campaigns are made. Right now, the "Backup" feature in MT is voodoo magic (and not in a good way.) No one has any control over it, and when tragedy strikes, they just hope something useful might be in that directory when they go desperately looking to see if MT has been backing up their work.
As for "Auto Save", I think it needs to be renamed to what it is: "Crash Recovery"
Once you make "Backups" function like people expect backups to function, then they won't expect "Auto Save" (aka "Crash Recovery") to do something it was not designed to do.
Then link the two by only having two settings in MT:
A) How often do you want to make a Campaign Backup?
B) How many Campaign Backups do you want to keep?
Require at least 1 Backup file (default to or suggest a higher number).
When a backup is written, a tiny "Crash Recovery File" would be created with the backup's name in it.
When MT is closed properly, the Crash Recovery File flag would be deleted.
If MT loads and sees a crash recovery flag, it will ask if the user wants to load the backup file associated with it (basically, the way it looks for Autosave files now.) However, if it doesn't see the flag, that means MT closed properly and there is no need for "Crash Recovery".
1. The autosave feature will have a setting that controls how frequently the autosaves occur. If the user is manually performing a save when it's time for an autosave to occur, the autosave will wait for the manual save to finish and, as soon as it's completed, the autosave will occur.
Discussion point #1: When an autosave is delayed like this, should it just be skipped entirely? If autosaving is for 'crash recovery", then there's no need to recover anything right after a manual save.
Discussion point #2: If the decision from DP#1 is to skip the autosave because a crash recovery file isn't needed, what about previous autosaves? Should they be removed? Suppose there are four autosaves and the user manually does a save (and there's no autosave being delayed), are crash recovery files really needed at that point?
2. There should be a limit (or limits) on how many autosave files MapTool should be managing at any one given time. For example, the filename pattern could be autosave-number.cmpgn, but if these files are for crash recovery only, do we need more than one?
3. Autosaves are currently put under the ~/.maptool/autosave/ directory. Should there be an option to change this? The main concern is that autosave files should (ideally) be on a different partition from where the .maptool directory is kept.
Discussion point #3: Consider also that multiple campaigns may need autosave files. If autosave files always use the same filename pattern (as described in #2, above), how will MapTool be able to tell an autosave for one campaign from an autosave for another campaign? What happens if MapTool is running multiple times simultaneously, each instance working on a different campaign?
4. Should network shares be disallowed for autosave files?
Discussion point #4: Consider that network shares generally take longer to write to and, on Windows, hold exclusive write locks to open files. Corollary: what should MapTool do if the interval between autosaves elapses while a previous autosave is still running?
Discussion point #5: It's probably expected that the "interval" field for autosaves is the amount of time between the start of one autosave and the start of the next one. But perhaps it should be the interval from when the first one completes until the start of the next one? What happens then if the first autosave takes an extremely long time (a network timeout, for example, if writing to network shares is going to be allowed)?