The confirmation box could include an option to open the backup folder.
I’ve been sitting on a related suggestion concerning how backup works, also a pretty simple visual cue… if I may drop it in here.
Just as the name of the backup zip file is the full name of the project with an appended timestamp, inside the zip file both the backedup .scriv project folder, and the backedup .scrivx project file, should be given the same timestamp.
So then inside zip file “ProjectName-bak-2022-02-26T16-18.zip” will be a folder named “ProjectName-bak-2022-02-26T16-18.scriv” and inside that folder will be a project named “ProjectName-bak-2022-02-26T16-18.scrivx”.
This would help ensure that the backup, when expanded and opened as a live Scrivener project, has a unique name that can not be confused with the actual project, which can easily be visually hard to distinguish from each other.
Just to clarify what I understand of the original suggestion (which I split this from as this appears unrelated), there would be no confirmation dialogue box. I don’t mind being informed when a process has completed, but being forced to confirm with the software that I understand that it completed a task which itself requires no actual decision-making from me, other than saying “OK”, would be a bit old school in my opinion.
That would just be an onscreen overlay that comes and goes, much like what you get when you reach the bottom of the document during a search and goes back to the top, or when switching revision mode writing on or off.
As to the rest, I cannot off of the top of my head think of any major issues with changing this procedure as you describe. It is in fact what already happens if you switch the .zip option off, in either manually created backups or those created by the automatic system. I’ll put it on the list for consideration.
Suggestions:
The latter is perhaps something to consider, if .zip is not a compelling option for you (network uploading would be the main reason to use it), then maybe you’d work better with that disabled, as your backups would be more clearly named.
Myself, I’ve never really run into a huge problem with that as I tend to treat restoration as a very isolated and binary event. I’m either doing it or I’m not. When I’m done I immediately discard everything that isn’t the result of the restoration, leaving me with one single project just like I started with. So maybe a tighter procedure can help as well, if the zip option cannot be disabled for other reasons.
remember also when view where you store your saves can have option to include date modified as info column when show files in detailed view in file explorer. Note date modified includes even the time it was modified in case did several saves on one day. I never include date in project title as have information at the fingertips. If don’t have the column available currently, click on bar at level where see file name will have options to click various data columns to add. (COA are the initials for my first novel)
It’s somewhat sad that saving a copy of a project (as opposed to backing it up) doesn’t force this behavior as well – that the actual new project name must differ from the original source project (even in the case of saving to a different location.) Think about how many support cases and posts over the years would have been saved because each copy was uniquely named (unless someone deliberately renamed it, in which case you can’t keep someone from shooting themselves in the foot.) it’s not perfect, but it would have reduced a lot of potential for confusion.
