Hi.
Is there a specific intention, or is it a simple oversight that zipped + timestamped backup files are named differently when using backup to vs a normal backup ?
Having more than one computer, I have good reason to on occasion want to backup to a specific/different location on my laptop. But when comes the time to select which backups to backup for good, it’d be a problem if I’d use backup to (which would otherwise be super convenient), as it messes up the order of the files if I merge in a single folder both backup “types”, when sorted by name. And having multiple projects running, I can’t sort by date created either.
Would be nice if this could either be fixed so that both use the naming scheme normal backups currently use, or that the scheme of one (or both) be user controlable in the options.
Thank you.
The “Backup Now” backup uses the same naming convention and location as Scrivener’s automatic backups, the options for which can be found in the Options/Backup pane.
The “Backup To” backup can have whatever name and location you want. In fact, one of the reasons why this function exists is to facilitate creating “milestone” backups outside of the standard automatic backup scheme.
Yes, yes.
That all makes sense, except that the starting point for the Backup to function uses brackets in the name instead or the -bak-DATE suffix, and it reverts to that even if you tweak it, with every single backup…
.Standard backup : - TEST BACKUP NAME-bak-2023-10-20T20-49
Backup to : - - - - - - - TEST BACKUP NAME [2023_10_20_20_52_45]
That limits the applications, like in the case I described above, as the two can’t properly be handled in a single folder once backups from different computers are collected into the main workstation.
In other words, sorting by name (and therefor by project, in the final backup folder) renders the timestamp useless. Files are no longer in chronological order.
You get me ?
. . . . . . . .
My plan was to use a synced folder (Google drive) to send those backups from my secondary computers (I have 2) to my main workstation. But I don’t want all my backups to travel up like that. So I was gonna use Backup to to backup to the sync folder every now and then. When it feels justified.
Currently I do it by hand. I move the desired backup to the sync folder. It works. It just gets annoying to do.
Mac Scrivener doesn’t do that. The default Backup To time stamp has no brackets, it’s just appended to the project name. And Backup Now appends the -bak, rather than prepending it. This might be something for us to look at normalizing.
I’m not sure I understand why sorting by the Created field in the file system doesn’t work.
If it were me, I would keep the Backup To backups separate. But then I only create those as “milestone” backups, so I don’t want them in with the “routine” backups to begin with.
Because I work on multiple projects. And don’t want them to each have their own backup folder. (That’d be even more work.)
Right now, say I have project A, B and C, sorting by date created my backup folder looks like :
A
B
A
C
B
B
C
A
. . . . . . .That won’t do…
I am aware that I intend to use it not as it is intended.
But since, exactly, the emplacement is different, does it need a different name as well ?
If the naming scheme was tweakable by the user, that could make more things possible. Like my use case. Or adding “MILESTONE” as a suffix. (Automatically, I mean.)
. . . . . .
This said, for sure if the Windows version was to do it like you say the Mac’s does (just “-bak” as a suffix at the very end, after the timestamp (?), and no difference other than that between the result of the two ways of creating a backup (?)), that would fix my little problem.
In short, the stamp needs to make the files list in chronological order when sorted by name. No matter which function was used to create the said backups. Even if a mix of both.
They don’t have to be named the very same. They still can be made discernable from each other, but whatever the difference is, it has to come after the timestamp.
If you guys every take at look at normalizing your zip names, please include iOS Scriv in that discussion, as those backup names are also formatted differently from Windows Scriv.
The choice to use a different naming convention for manually created backups is very deliberate, so that they do not inadvertently enter the rotation for backups that would be periodically deleted as they grow too old, if one targets their main backup folder as the save location. If what you want is a manually fired off backup that is part of the rotation, that is precisely what Back Up Now is for.
Otherwise I do agree it’s a bit odd that Windows manual backups have their own naming scheme that doesn’t match the Mac/iOS manual backup scheme. There may have at some point been a good reason for that (project format compatibility, particularly during the v1/v3 years), but I’m not thinking of a good reason now.
Makes sense.
And I can see how the potential issue easily supersedes the usage I wanted to make of it.
Perhaps if one day you guys would consider making the name scheme customizable for Backup to (?)
Otherwise, yeah, nevermind, I guess.
. . . . . . . . . . . . .
[EDIT] But on second thought you know what ? If you guys still give them different name schemes, backups made using Backup to won’t get automatically deleted like the normal ones. (As it is currently – the difference in the naming is where it happens, or doesn’t, more precisely.) (But → ) Even if the difference in the name is after the timestamp. (?)
And the timestamp coming first is all that’s needed for the two to sort properly when in the same folder…
Which would make it usable the way I intended to. (Among other things.)
Or can’t perhaps Scrivener spot the difference in the naming if it comes after the ever changing timestamp? (For the max backups retained, that is.)
[This above is all awfully formulated. What I mean is : Can't the difference between the two be after the timestamp ?]
Perhaps have a look, see if it is doable or not if one day you guys decide to normalize the naming across platforms… (?)
One way or another : as far as I am concerned, my current issue is not a problem without a solution. So it is OK. As I said, I can already get what I want. – It’s just that I have to handle it manually. (It gets annoying at times, but it ain’t terrible.)
. . . . . . . .
[EDIT2] As a matter of fact I think I just figured a solution. Since the original request concerned backups that I want to send up to my main workstation via a sync folder and that my issue is with the way Backup to backups’ names mismatch and won’t sort properly along the standard backups, I will test using Backup to as my main backup method for my satellites computers, and the standard backup as what points to my sync folder. (In the end, and there available if I have an issue, the backups that I don’t send up the sync folder I will still have on the satellites computers. So it is all the same. And the ones I’ll send up the sync folder will now have names that match those of my main workstation.)
This should do. (As in why did I not think of it before…?)
As for what I do, I point each device’s automatic backup folder at the same synced directory, all using the same settings. They thus all contribute to the “recent 25” pool equally, and without complication. I know the most recent .zip in that folder is what I want to extract from when I start a session—I don’t even have to remember where it came from, it might have even come from the same machine, it doesn’t matter if it did.
For manual backups—the ones I want to keep readily available for longer than 25 sessions—I do put those in another folder that is also synced—just to reduce clutter. It’s a personal preference, but for me, that central backup folder is pretty cluttered just storing the 25 pool for every project I’ve been working on in recent history. There can be hundreds of files in there at any given time, so for the special backups I want to have earmarked, I’d rather they be more accessible.
Therefore my filesystem setup looks like this (in excerpt):
ark
bak
scriv_auto
scriv_manual
Having one single consistent target for manual backups means I can simply hit the shortcut for it and mash the Enter key, then get back to it.
(Automatically, I mean.)
why did I not think of it before…?)