MacOS Monterey?

[GBrachetta]

Hi, I wonder if this is still current on Monterey, as Homebrew installs now on /opt/homebrew rather than /usr/bin.

It would be great if it did, because I don't want to send to my NAS all node_modules and virtual environments!

Thanks!

[sandrodz]

It doesn't seem to work.
I still see node_modules in timemachine backup. And provided command:

sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'" doesn't show what asimov excluded while running the command.

[sandrodz]

@stevegrunwell Do you still use this on Monterey? If you've a minute could you please take a look.

[stevegrunwell]

Unfortunately, I don't have access to a machine running Monterey to test; apparently, the new OS dropped support for pre-2015 MacBook Pros, so my late 2013 will be stuck on Big Sur for the foreseeable future 🙁

Fortunately, the script itself should still work just fine as it doesn't rely on the Homebrew installation path; instead, the plist file will need adjustment when running on Monterey. It looks like Homebrew itself may have updated the formula, so I'd recommend uninstalling and reinstalling Asimov on your system:

$ brew update && brew reinstall asimov

Once that completes, you should be able to enable the daily schedule:

$ sudo brew services start asimov

Please report back with your findings!

[GBrachetta]

It would be great to know if this is still working on Monterey. Maybe this is easy for you to give it a go, @sandrodz ?

@stevegrunwell Is the plist modification (for the new /opt/homebrew/ path) something to be done manually? Or is there a way for asimov to check for x86_64 or arm64 and create the plist accordingly?

And are there any risks of messing up time machine and rendering it non-operational if something goes wrong?

Additionally I'd love to know how easy is to create new rules: For example for .venv directories, in my case I'd need to be Pipfile the trigger rather than requirements.txt for I work with Pipenv instead of pip.

Thanks, and I cross fingers it all works well on Monterey, as currently my backups take very long for all dependencies and virtual environments created daily. 😊

[Jamesking56]

Starting the service doesn't seem to work for me even after reinstalling on Monterey:

Warning: Taking root:admin ownership of some asimov paths:
  /usr/local/Cellar/asimov/0.3.0/bin
  /usr/local/Cellar/asimov/0.3.0/bin/asimov
  /usr/local/opt/asimov
  /usr/local/opt/asimov/bin
  /usr/local/var/homebrew/linked/asimov
This will require manual removal of these paths using `sudo rm` on
brew upgrade/reinstall/uninstall.
/Library/LaunchDaemons/homebrew.mxcl.asimov.plist: service already bootstrapped
Bootstrap failed: 37: Operation already in progress
Error: Failure while executing; `/bin/launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.asimov.plist` exited with 37.

[haliliceylan]

I just installed, i will share results.

[keegan-lillo]

@Jamesking56 You need to run sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.asimov.plist to unload it.

[carakas]

seems to be working

[skywalker123p]

@carakas I have same issue, how did you fixed it? when I run manually asimov I see files are processed for ignore in time machine. but then I check via sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'"
it do not show me those new entries and backup actually very slow due to this.

can you please let me know thanks

[reorx]

I believe that a brew service is unnecessary to make this tool function. The .plist file displays that the tool relies solely on an interval loop to execute the asimov script every 24 hours. Crontab is a simple and stable alternative that can achieve the same result. All you need to do is add the following code to crontab -e:

0 22 * * * /opt/homebrew/bin/asimov

This code will execute the asimov script at 22:00 every day. Although it's not perfect, it's enough for this case.

[emsearcy]

You can use tmutil isexcluded <path_to_directory> to test whether or not asimov properly excluded the directory.

Running mdls <dir> on some files I had previously excluded, vs. ones newly excluded, seems to suggest that MacOS is no longer adding the com_apple_backup_excludeItem metadata, even though if I run xattr <dir> or ls -ld@ <dir> I can see that they are setting a filesystem extended attribute ... which doesn't help us use mdfind to list them, though.