"brew upgrade" results in deleting gigs of data without any prompts!

I haven’t run brew on a build machine in a few months.
Today I run brew upgrade and it did its usual stuff.
Afterwards I started to tweak the configurations of some of the newly updated apps.
It was only then that I noticed that the data of one of my apps is missing.
I scroll back to look at the brew upgrade output and see this:

==> **`brew cleanup` has not been run in 30 days, running now...**
Removing: /usr/local/Cellar/artifactory/5.4.1... (8,557 files, 1.2GB)
Removing: /usr/local/Cellar/artifactory/5.5.0... (91 files, 78.6MB)
Removing: /Users/dev/Library/Logs/Homebrew/jenkins... (2 files, 65.3KB)
Pruned 16 symbolic links from /usr/local

Uh…thanks brew default behavior for just deleting 1.2GB of my important data without asking me!

I am seriously trying to stay composed here.
This seems obtuse to me.

Cleanup should not by default actually delete any content with zero interaction!
The behavior should either be to prompt the user or to require a command-line flag to automatically respond yes to the prompt.

Something like brew upgrade -f.

Yes, I [now] know about the export HOMEBREW_NO_INSTALL_CLEANUP=1 option, but it is a little too late now.
Yes, I know my app’s [artifactory] data should be in a version isolated folder; I thought it was and wherever it is was just the default location of the brew installation. ‾_(ツ)_/‾

Thankfully I have an old backup from a few months ago that I can recover most of my data with, but this seems seriously obtuse.

Please turn this zero-interaction behavior off by default.
If someone wants to delete things they can have the power to approve it to automatically do so from the command-line with a switch.

Pv

Sorry, we won’t be making this change. We’ve gotten a ton of feedback over the years about how brew cleanup should run automatically in order to save multiple gigabytes of disk space. Before, most users were completely unaware that they had to run cleanup occasionally to clear out old bottles. Changing the behavior to opt-in is a clear step back for most users. I also want to point out that most package managers have this behavior as well.

1 Like

Understood that is nice behavior for the masses, but fact is that it is destructive action.
Feel free to automatically clean up, but to be a good citizen brew must prompt the user before it starts destroying files in an unrecoverable way.

This is a command-line tool, used either automatically or manually, with unrecoverable results.
People can learn to change if the behavior becomes annoying to them.

Automatically cleanup, but prompt the user Y)es, N)o, A)ll for each deletion and they will learn to either always manually answer affirmative, or if they find that annoying learn to use a command-line switch or environment variable to automate doing so.

I’ll gracefully bow out of this request, but I seriously don’t understand how prompting, with education of a command-line or environment way to override, would block anyone or be a step backwards…and I think leaving it this way could seriously seriously seriously F up many people’s day. :confused:

most package managers have this behavior as well

One last word: brew isn’t a package manager. Packages rarely have data in their install folder. Brew installs apps, that may have data in their install folder.

Brew’s tagline is literally “The missing package manager for macOS (or Linux)”. I think a better solution here is to make sure the data is stored outside the install directory (as it should be) to make sure it’s retained between updates and not deleted by cleanup.

Touche about the tagline.
I was thinking more like npm package management of libraries only.

I think a better solution here is to make sure the data is stored outside the install directory

But you can’t really guarantee all apps will behave that way.
Show me a user that doesn’t know about brew cleanup, and I’ll show you a user that doesn’t know if their data is outside of the install directory.
Even a user that does know and run brew cleanup is going to be in for a bad surprise if all of their data is removed automatically by default without a single prompt.

I thought disk space was getting cheaper and cheaper, so why risk deleting data in an unrecoverable way just to save some cheap space?
I guess gone is the day of caring about deleting people’s data.

The current behavior is a bad citizen. You are now aware that some users are going to be very hurt by this default behavior in the future, and you have a chance to mitigate it.

It shouldn’t be up to the user or packager to keep the data outside of the install directory. It’s up to the software. I agree that user data shouldn’t be deleted, I just disagree who’s at fault.

It shouldn’t be up to the user or packager to keep the data outside of the install directory. It’s up to the software.

If it is up to the software to keep its data outside of the install directory, then any app not confirmed to do so should have its formula blocked/banned/excluded-from-cleanup.

I agree that user data shouldn’t be deleted, I just disagree who’s at fault.

The fault in deleting the data is in the thing that deleted the data…especially without prompting.

I fundamentally disagree that it is acceptable for a utility to bulk delete data without confirmation.
The is why rmdir only deletes empty directories, and why rm has -f and -r options.

Continue to do as you wish, but you have been warned that users’ data is at risk [for any updated app that stores its data in the install directory…which I would think could be a lot].

@paulpv has a point.

In my case I found out about the introduction of automatic brew cleanup when my dev system suddenly stopped working. Out of nowhere MySQL was gone. Latter I found out that all versions apart from the most recent one had gone. It took me hours² of troubleshooting to get everything working again for legacy projects.

What I still today find troubling is that versions, which had been linked to before brew upgrade is run, get deleted!

For example: in my case I have to use MySQL 5.x for some legacy projects, because the mysql adapter does not compile against MySQL 8. For that reason more often than not I switch to that version. Now when I run brew upgrade or even worse, when brew upgrade is triggered by, for example, RVM, the newest version is installed and all of the versions I have installed including the one which was linked and active get deleted.

I get it that someone might decide that automatic cleanup is the way to go. I do not agree and find a prompt a good way to deal with it, but ok. But why does automatic cleanup delete older versions which are active?

Thanks you @paulpv for bringing export HOMEBREW_NO_INSTALL_CLEANUP=1 to my knowledge. I will dive into it. It has to go into .zshrc right? Or is there a better place in homebrew somewhere?

1 Like

Keeping around legacy versions is better done in a tap anyway to prevent upstream work from altering the state of it.
The export statement should be in your shell config so ~/.zshrc seems like a good place.

@SMillerDev thanks for the input!

Yes indeed I have to find a suitable tutorial and finally learn everything there is about taps.

I also would like to finally find out why on my system mysql@5.5, 5.6, 5.7 + the rails mysql gem 2.8.1 do not get along, while /usr/local/Cellar/mysql/5.7.21 works! Over time it has taken me already days² here and there and is still a mystery to me! But that is another story.

Yes indeed I have to find a suitable tutorial and finally learn everything there is about taps.

https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap should get you some of the way already.

I also would like to finally find out why on my system mysql@5.5, 5.6, 5.7 + the rails mysql gem 2.8.1 do not get along

I’m not very knowledgeable about gems but if it’s an incompatibility between a gem and a mysql version you could report that upstream.

1 Like

Does brew pin honor not being automatically removed?


It’s not a firm lock on the end-user, it’s just a firm lock on brew update/upgrade mechanism itself, I believe.

Pv