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.
-rob.
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.
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.
-rob.
That's not a "macro", that's an APP!
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.
-rob.
Version 2.7 is out now, with only a couple very minor changes:
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.
-rob.
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.
-rob.
Hello Rob @griffman,
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.
-rob.
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.
-rob.
thank you. I think that settings the number of backups as you suggested is key
!! That's a lot (for me at least). If you ever feel like pruning, I love to sort by Date Used and start (archiving and) deleting from the bottom:
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.
-rob.
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 ?
Sorry to test your patience !
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
-rob.
OK. I read and worked through your example above and the wiki article, and it I am starting to understand. I will do some testing. thank you very much !
Here's a bit more to further clarify things...
If you use ls with the -i option to show the files' inodes, that will show you exactly where each file resides on your disk. If files are hard linked to the same location, they are all pointing to the same file, even if the names are different. Here's the output for ls -i on the three sample files from above:
$ ls -il
total 24
106250477 -rw-r--r--@ 3 robg staff 108 Jan 25 13:15 link1.txt
106250477 -rw-r--r--@ 3 robg staff 108 Jan 25 13:15 link2.txt
106250477 -rw-r--r--@ 3 robg staff 108 Jan 25 13:15 wordlist.txt
The inode is the first number in the output, and it's the same for all three files. Ergo, each is hard linked to the same physical location on the drive. If you were to edit wordlist.txt, the contents of link1.txt and link2.txt would also change, because it's only one file.
-rob.