Weird app deletion via policy

Try looking at the filenames outside of finder, like in a terminal/shell. This recently bit me in the ass when an adobe apps finder name was different than the actual filename. Just a thought!

Oh yeah, I remember seeing something like that before with some other programs. How is that possible that the name displayed in the Finder can be different from what displayed in the command line anyway?

Unfortunately the Finder names for both versions of the Univago app do agree with the command line names. So that's not the issue here.

FWIW, I have other policies set to do something similar, but none of those have spaces in the file name. So when I have the policy run rm -Rf /path/to/filename it works as expected. I wonder if this could be a bug because there's a space? Like it has a problem withrm -Rf /path/to/file name More testing is needed. Luckily this isn't a showstopper. I can always go back and delete the old app manually via ARD after the new one is installed.

This does sound bug like. As a workaround have you tried wrappering the rm call?

/bin/bash -c 'rm -Rf "/Applications/Univago Client.app" '

@AVmcclint, another alternative is to use the "Search for File by Path" option in the same Files and Processes policy payload. Enter in "/Applications/Univago Client.app" (I've entered file names with spaces without having to escape the space or putting the path in quotes, but you can test it both ways) and then check the "Delete file if found" box.

@AVmcclint I've run into the problem with the Files and Processes section not respecting double quotes when trying to execute lpadmin commands to setup printers. I was forced to use single quote marks to surround my commands. I believe it was a known product issue (D-008699). When we upgraded from 9.63 to 9.72 it broke. I thought they had this issue fixed with newer versions of the JSS but since the lpadmin commands still work with the single quotes I haven't bothered to test this out. Have a look at this.

Very interesting. I'll have to remember that defect. I guess if I REALLY needed to run a command with quotes or escaped characters and JSS didn't like the perfectly legal command I want to use, I can always just write a 1 line script that gets attached to the policy. That's unfortunate because I like to think of the Files and Processes section as a "set it and forget it" box for very simple commands that shouldn't need a whole script dedicated to it.

Well you may just want to work around this, I can think of a few ways:
- preflight script to delete old version
- standalone script to delete old version, then trigger policy to install new version.

I usually opt for the preflight script.

This is very strange. I decided to test out whether the "Search for File by Path"/"Delete file if found" function would work. I created a test policy with that option set. I then made two copies of an app in /Applications (Self Service.app in this case) and renamed them "Univago.app" and "Univago Client.app". When I ran the policy it did delete the latter while leaving the former alone. So that should work for you.

I also tried your original command rm -Rf /Applications/Univago Client.app in the Execute Command field (clearing the above settings and flushing the policy), and that also worked for me (deleting only the two-word-named app and leaving the one-word one alone). So I'm not sure why it's not working for you.

Here's the weird part. After I made the copies of Self Service.app and renamed them, I launched them just to see what would happen. "Univago.app" launched Self Service just fine, but "Univago Client.app" would give me an error telling me The application "Univago Client.app" can't be opened. But if I move the app out of /Applications, it would launch, but not back in /Applications. I took another app in /Applications, Fetch in this case and gave it a two word name "Fetch Now.app" and it launched fine. I renamed it to "Univago.app" and it launched, but when I rename it "Univago Client.app" it would not open!

(My test policy is set to Once per Computer, not Ongoing, so it's not like the jamf binary could be trying to remove it. Plus the check-in interval is longer than that. Going to reboot and see if I still have the problem.)

Edit: I rebooted my Mac and could not replicate the weird issue of not being able to open any app named "Univago Client.app" in /Applications after running the test policy, and I was still able to delete "Univago Client.app" using either the rm command escaping the space or putting the path in double quotes or using the "Search for File by Path" function, all within the Files and Processes policy payload.