Version 2.3 is out, and it's mainly a cautionary release: First, use Default Folder X's settings to disable it when Keyboard Maestro is active, and the restart Keyboard Maestro—it interferes with the process I use to set the export folder location. I plan to get the trial version of Default Folder X and see if I can work with it, but for now, it's best to disable it.
The second caution is that if you have macros and/or groups whose names include ###, then MBU is likely to have issues. This happens to be the string I chose to use as a delimiter when working with data that goes to and from the database, and finding the delimiter in unexpected spots will probably cause issues. In the next version of MBU, I'll change my delimiter to something more obscure, but I don't want to rush that change out, as the use of the delimiter is extensive, and I need to make sure I find and change them all.
There are also some fixes in here, mainly related to analyzing and writing modified macros when there aren't any…turns out writing them doesn't work so well if they're blank.
Full release notes
Caution: If you use Default Folder X, it will probably prevent MacroBackerUpper from successfully exporting its backups. For now, the solution is to disable Default Folder X within Keyboard Maestro.
Caution: If any of your group or macro names contain ###, you will probably have issues with the macro. I chose that string as the delimiter to use in all database operations, and things will not parse correctly if it's found in your naming scheme. A future update will change my delimiter to something much more obscure.
Added code to make sure the Command key won't work in the delay box if there are no modified macros to examine.
Fixed a mistake that prevented the creation of (backup) UUID files on the first run by a new user.
Added a check to make sure there are modified macros before updating database.
Added a check to make sure there are modified macros before writing to the "modifieds" file.
Changed the code related to replacing entire directories with hard links to account for dot-named files. Related: TIL that the * shell wildcard won't affect filenames that begin with a dot.
As always, you can install from the first post in this thread, or by checking for updates from within the macro.
Version 2.4 is out, with the promised change to the delimiter—you can return to using ### in your names, but please, do not use ←🔸→ … seriously, don't. You will break all sorts of things :).
The other news is that I figured out a way around the Default Folder X problem. Users of Default Folder X can leave it enabled in Keyboard Maestro; the macro will disable it to run the backup, then re-enable it. This is what happens when developers include good AppleScript support in their apps, so thank you, St. Clair Software!
If you are a user of Default Folder X, you will see this dialog the first time you run version 2.4:
Please say OK to that dialog! You will only see it one time, and if you say Don't Allow, MBU won't be able to disable Default Folder X, and the macro will have issues.
There was one very minor bug fix, too, but that's it—full release notes below.
2.4 Release Notes
Users of Default Folder X, rejoice! You can now use MacroBackerUpper without making any changes to your Default Folder X settings: MBU will disable Default Folder X until the backup is completed. Thank you, St. Clair Software, for the very nice AppleScript support!
Changed the delimiter used (behind the scenes) for all database interactions. It used to be ###, but there are at least two people out there who use that in their macro or group names. So now it's ←🔸→ … and if any of you are using that trio in your naming…well, I'm sorry, but you can't use MBU until you rename those macros and groups :).
Fixed a bug that was causing the total disk space value to not show in the summary dialog at the end of a run.
Current users can use the update check to download the new macro, or download from the first link in this thread.
This version was tested by my ever-vigilant group of testers (thanks so much!), and it worked well for them, so I'm not expecting any issues. But if you have any, of course, let me know!
And 2.5 is out now, linked in the first post above, or if you have MBU installed, run the Check for Updates macro. I had to change how it looked for Default Folder X, as those using DFX through SetApp weren't detected by Keyboard Maestro's "is application active?" action. No other real changes, just some cleanup of no-longer-needed large instance variables.
And 2.6 is out now, with a bug fix and a behavior change (thanks to @_jims for both of those!), and a couple other minor changes.
Full release notes for 2.6
Added a Trim filter action to the sample dot-named group to remove a line break.
The update checking macro won't notify you that you're already up to date if it runs on its periodic timer. If you run it manually, you will see a notification.
Undid a change made in 2.2 that removed a supposedly unneeded if-then statement in Setup. Turns out it was needed after all (in cases where the backup folder goes missing but the backup location variable is set).
Updated the macro tracking action for those who use my Macro Usage Counter macro.
The 2.6 download is linked in the first post, or just check for updates from within the macro to download it directly.
Well, it doesn't actually do the updating for you, just alerts the new version's existence and downloads it from my site. But it does mean users don't have to check the forum for newer versions.
It's not overly complicated; I wrote it up a couple years back:
I do use two servers to try to add some file integrity protection: The downloads come from my server, but then they're verified using SHASUM values downloaded from a different server. I've been pretty happy with how well it's worked for me.
Version 2.7 is out now, with only a couple very minor changes:
Trimmed a disk space usage variable that escaped previous trimming attempts.
Forgot to add a trigger check before attempting to close the task list window. This would generate an error in the Keyboard Maestro log file. Trigger check now added.
Neither affected functionality, but as no issues have appeared for a few weeks, I thought I'd release it now. Download via the link in the first post, or use the in-macro "Check for updates" macro.
Version 2.8 is out, and it's a simple maintenance release with some variable-naming changes, and it re-enables the 'first run' macro, which was left disabled in the last update. The in-macro updater should show the new version, or you can download from the link in the first post.
I was looking at your very interesting web site, came upon your Intro to MacroBackerUpper
which looks like an absolute gem and I immediately wanted to install the macro.
I have one concern before doing so and after reading the documentation:how big a potential problem is space expansion if the folders are moved to another drive a problem ? Just thinking about it: after years of bi-weekly backups, the total number of macros and folders could be gigantic.
I understand that it can easily be managed if the folder is moved to another location on the same drive using the macro settings, so that's not a problem.
A few examples which concern me: if i put the folder in dropbox, what happens in the folder on the dropbox server ? what happens if I copy the folder to my google drive ? what happens on my carbon copy cloner backup SSD? What happens if my primary drive crashes and I have to restore the OS and migrate the data from a backup ?
If the potential problem (space expansion) is less than 10 GB, no problem, but if the potential expansion can be of for example 100 GB, it makes me nervous.
thanks very much for this contribution to the library.
That would depend on where you move it, how you move it, and how many backups you have. The math is pretty simple: Take the size of a single backup (back up to a new location to see the size of an individual backup) and then multiply by the number of backups. That would be the non-linked size.
But if you move the backups using the manager built into the macro, it will (if it can) retain the hard links. So moving it to another local drive within the macro will be fine. As far as I know, none of the cloud services support hard links at the server level, so I think the online size would be huge (though the local size should be small, because that's still a folder on your drive).
A single backup of my 750ish macros takes 24MB, or .024 gigabytes. If I had 416 backups, that'd take 10GB uncompressed. Or 4,160 would use 100GB. I don't think size will be an issue. However, the macro has that covered, too: You can set a limit on the number of backups. I have mine set at 75, as that generally covers way more than enough time for me.
Now I understand. Everyone of my backups of all macros as a folder is 560 MB which prompted my question. I have more than 5,000 macros, a testimony to how big a mess they are, not how proficient I am. I will have to sort this out before I install your macro, but frankly, I would not know where to start.
You can install it and run it once, and it'll show you the size in the summary dialog at the end. Future backups will only add a few megabytes, until/unless you copy it somewhere that doesn't support hard links.
If you don't want to use it, you can just delete it after the first backup, and you'll be clear.
thank you very much for the suggestion which I will implement immediately
1- by archive, do you mean backup and delete or should I install a special archive macro or plug-in to do so ? I looked up "archive" in the wiki and found nothing.
2- another issue I have a size. I notice that some macro (when I look at a backup all macros to folder) are large 10 to 35 MB for a single macro. Most large macros are innocuous (reminder, help menu) and seem to have in common the fact that it contains a display text in a window containing an image (a technical image namely a screenshot).
thanks again
If I do archive them first, I usually just drag them to a folder in Finder, zip it and stick it in a general purpose "archive" folder somewhere on Dropbox. I almost never go back into them but just in case, right?
This is probably related to storing the image itself inside the macro:
A better way (once you have finished designing the macro and won't require much tinkering with the screenshots anymore) would be to use a path to the image instead. @iampariah has a tool for converting them, though I have not tried it myself yet. I am not sure if it will work for Display Text in a Window actions, but this thread may get you going in the right direction:
I ran the macro and it works beautifully. Congratulations.
I am puzzled by one comment in the documentation: if the total backup folders take up too much space, the user can always manually delete older backup folders. Wouldn't that defeat the purpose of the space saving hard links ? If a macro has not been modified since the first backup, and all subsequent backups link to that macro, how can I delete the oldest folder ?
thanks again
I will paraphrase and probably get some details wrong, but think of it this way: A hard link is just a pointer to a spot on your drive. When you create the original file, a hard link is essentially how its name is associated with its location on the drive. When you create additional hard links to that same file, they're all just pointing to the same spot on the hard drive.
You can delete any of the hard links, including the original, because that simply removes that hard link pointing to that location on the drive. All the other links will still work, because the data on the disk is still there. Here's a real example:
$ ls
wordlist.txt
$ cat wordlist.txt
LYRIC STILL BEZEL MEALY SLUNG BEZEL
AUGER RELIC YOUTH PENCE CRAZE LUNAR
SKILL BLOCK SIGMA SHALT SPREE EAGLE
$ # Create two hardlinks to the original file
$ ln wordlist.txt link1.txt
$ ln wordlist.txt link2.txt
$ # Show all the files
$ ls
link1.txt link2.txt wordlist.txt
$ # Remove the original file
$ rm wordlist.txt
$ cat link1.txt
LYRIC STILL BEZEL MEALY SLUNG BEZEL
AUGER RELIC YOUTH PENCE CRAZE LUNAR
SKILL BLOCK SIGMA SHALT SPREE EAGLE
$
So that's why you can delete any of the backups without messing up the hard links. Obviously, if you delete all the hard links to a given file, that file will cease to exist.
I read your description (thank you) and googled Mac OS file hyperlinks.
Let's say that I have only 1 KM macro which I backup daily about 90 times using MacroBackerUpper from 1 sep to 1 dec, and let's assume that the macro in question remains unchanged (never been edited).
The 1 Sep backup consists of 1 macro and all other 89 backups are hyperlinked to that never edited macro ie they are pointers to that macro, to that location on my drive which corresponds to the 1st backup.
So how can I delete the 1 sep original backup ? All subsequent hyperlinks point to what ?
The problem is in this bit of your description of what happens: The links are not to other files on the drive. The links are to a location on your hard drive. Every backup of that identical macro points to that same location on the hard drive. It doesn't matter if you delete the original, because the subsequent ones aren't pointing at that file, but rather, at the location on the hard drive where that file resides.
See the output in my example above, it's that exact scenario: One original file, two files linked directly to it via the ln command, then I delete the original and show that the linked file's content is still there.
Does that make sense?
Don't google file hyperlinks, you want to read about hard links: Hard link - Wikipedia
