Installation fails on macOS 11.2.2 about mailtrackerblocker HOT 5 CLOSED

Indeed! I should have checked how old the link was - no idea where it came from. I've been dragging this user profile from Mac to Mac since forever, so maybe this is ruins from an ancient civilisation of developers or something.

The installer could detect if /Library/Mail/Bundles is a dangling symlink, and auto-fix it? -L means it's a link, ! -e means does not exist.

if [[ -L "$targetDir" ]] && [[ ! -e "$targetDir" ]]; then
  rm "$targetDir"
  mkdir "$targetDir"
fi

The test could also use -w instead or on top of -e to see if we can write to the target.

from mailtrackerblocker.

Workaround:

This was caused by /Library/Mail/Bundles being a symlink to /System/Volumes/Data/MailBundles/Library/Mail/Bundles which did not exist (and wouldn't be writable anyway).

One workaround is to:

rm /Library/Mail/Bundles
mkdir /Library/Mail/Bundles

from mailtrackerblocker.

@grischard Thank you for the detailed report (and for solving your own issue?😅).

This seems to be the same as #27. I'm not sure why some users have this symlink to begin with. This makes me a bit iffy about touching it through the postinstall script.

from mailtrackerblocker.

Thanks for the insight.

I have a clean Big Sur setup (i.e. no prior migrations) and it doesn't have this issue. But I might end up doing your suggestion since this doesn't seem to be an isolated case. Lots of users end up inheriting odd settings like this for every macOS update.

from mailtrackerblocker.

We can close this then. Thank you very much!

Clean Big Sur setup? I envy you :)

from mailtrackerblocker.