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
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 !
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.
If you have the patience, could you give an example based on the above situation where you actually do want to delete everything related to that macro. Basically, you would delete all backups related to that macro ?
thank you
Version 2.9 is out, linked in the first article in this thread or via the in-macro update checker. The only change in this version is how duplicate-named and leading-dot-named macros and groups are handled.
Before, a sample of such items was included in the dialog box. But if you wanted to change all such macros, you had to run the macro a number of times to see all the macros. Version 2.9 now writes the full lists into two files in a temporary folder, and opens that folder when the macro finishes. This should make it much easier to find and change all such names, for all those so inclined.
If you tell MBU to ignore dupes and dots names, then nothing changes—the files aren't created, because the entire routine is skipped.
Great macro which I use a few times a week.
Sometimes the macro "freezes" for lack of a better word and I have to manually quit.
Below are 2 failed attempts followed by one successful run.
How sould I troubleshoot this issue ?
thanks very much
