macOS BigSur upgrades delete our application files

Hello

We develop our macOS-compatible software. Our package installation is done under the /Library/Ossec folder. After a macOS upgrade, the folder /Library/Ossec/queue/alerts/ is removed, always. So, after the upgrade, the software can't start again because of the removed folder. This is causing a lot of problems between our customers and users, it's really annoying. How can we avoid that?

Additional information: https://github.com/wazuh/wazuh/issues/7793

Thanks for the help
Answered by Wazuh in 673771022
Hello

Yes, we are taking into consideration the second approach. But in parallel, we would like to debug. How you do recommend debugging this?

I recreated different folders pointing to the removed one, faking the filenames, etc. None of them are removed. I searched in all logs, I run sysdiagnose and searched there, but no clues.

Thanks for the help
Well, that’s weird. Have you filed a bug about this already? If so, what’s the bug number? If not, please do that now and then post your bug number here.

Also, can you reproduce this without installing your entire software? For example, try this:
  1. Set up a VM running an older version of mac OS 11.

  2. Snapshot that, so you have it handy to repeat the test.

  3. Create the /Library/Ossec/queue/alerts directory by hand (see below).

  4. Upgrade that VM.

Does the get removed in step 3?

Note To create your directory by hand do this:

Code Block
% sudo mkdir -p /Library/Ossec/queue/alerts


Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Hello

Thanks for the reply.

Yes, I reported id. The ID: FB9092024. And yes, it is totally reproducible. My software is working fine before the upgrade, and after, it stops because of the folder removal. If I create by hand the folder, and I start it again, it works perfectly. But, obviously, we can't ask our customers/users to re-create the folder by hand in every OS upgrade.

Please let me know if I can give you more details and thanks a lot for the help. This issue is critical for us.

Regards,
Alberto R

Yes, I reported id. The ID: FB9092024.

Thanks for that.

If I create by hand the folder, and I start it again, it works
perfectly.

Right, but that’s wasn’t what I was asking. Rather, I’d like to know whether the system deletes /Library/Ossec/queue/alerts on upgrade if your software isn’t installed. That’ll tell you whether the problem is with that path or there’s something else in your software that’s triggering it.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Oh, ok. I understand. Let me try it again and I will come back to you.
Thanks.
Hello

I tried without my software and the folder was not removed. I will try to reproduce again but touching/faking the "socket" files that are created in this folder by our software.
I couldn't reproduce it because a "socket" can't be copied. I did some more tests with symbolic links to the socket, with paths... blocking the folder "alerts" but always the same: "alerts" folder, that contains the sockets, it's removed.
We have other folders with more sockets but any of them are removed.

Any idea?

Any idea?

There’s two ways you might approach this:
  • Track down the reason why your product triggers this bug and then change the product to avoid that.

  • Ignore the reason why this is happening and just implement a self repair feature.

Normally I’d prefer the first approach but in this case that’s not going to be easy. Even when using a VM, having to run an OS update for each test cycle really slows things down.

Given that, you should consider the second approach. Is there a way for your product to detect that this has happened and simply re-create the required directory?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Accepted Answer
Hello

Yes, we are taking into consideration the second approach. But in parallel, we would like to debug. How you do recommend debugging this?

I recreated different folders pointing to the removed one, faking the filenames, etc. None of them are removed. I searched in all logs, I run sysdiagnose and searched there, but no clues.

Thanks for the help
Sorry, I marked as solved accidentally
Additional information:
I noticed that, creating a dummy file inside the folder /Library/Ossec/queue/alerts/ prevents the folder to be deleted by the Big Sur upgrade

Sorry, I marked as solved accidentally

No worries. Unfortunately that’s hard to fix, at least right now )-:

How you do recommend debugging this?

No (well, nothing beyond what you’ve already tried). Debugging install-time issues is tricky.



Oh, wait, I just took another look at your bug and there’s some new info there. It seems that this is a known issue (r. 36393725), where the upgrade process removes empty directories in /Library/Preferences during the upgrade.

I noticed that, creating a dummy file

Right, that’s good evidence for the above.

The canonical workaround for this, as illustrated by Homebrew, is to add a .keepme file to this directory.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
macOS BigSur upgrades delete our application files
 
 
Q