I'm creating a macro that moves all files in the Trash to a folder in my secondary internal disk and then zips the folder while protecting it with a password, but for some reason it's not working. It works when I use the Terminal, but not with KM.
Here's the macro:
Empty Trash to Secondary Disk Macro (v11.0.1)
So everything works up until it runs the Shell Script action.
The Engine Log shows this: Task failed with status 16
I'm thinking that maybe the issue is related to the password, because when I'm using Terminal it asks me to create the password and confirm it after that, but KM doesn't do that, so I wonder how that can be achieved (if possible at all?)
I'm not sure how secure you need this to be, but did you try using the -P flag to specify the password in the script action? It's not as secure since you'd have to store it in the macro, but you could enter it in a password field in a prompt action earlier in the macro and it will be cleared from memory once the macro finishes running
Thanks for the quick reply.
I'm not experienced with Shell. I copied that from a website.
So the issue is indeed due to the password, because I tried the same action without the -er and it worked. Now what I noticed is that the folder was 380 MB, but the ZIP was just 244 bytes and when I unzip it, it only has the folder, not the files.
Do you know what could be causing this?
I need to figure this out first, before trying the password thing.
I tried a new version where I added a 20 second pause before the script, because it could be that the files didn't have time to be moved, but I get the same 244 bytes ZIP. Weird...
Another issue I'm facing (related to this post I just created):
Some files are not being moved, because the path to the .Trash is not included in the FOR EACH action. I noticed that I had files that had this path: /Users/dannywyatt/Library/Mobile Documents/com~apple~CloudDocs/.Trash
So how can I move all files in ALL Trashes, system wide?
I'm no expert, but MacOS stores trashed files in a couple different places, but there isn't a programatic way to view all of them as far as I know.
Each volume should have it's own .Trash or .Trashes/.Trash/ folder. Including cloud storage drives, along with your User's .Trash folder, which it looks like you located. You should be able to go through all of them and add them to your macro. You can also go through the trash contents and get info and view the paths of all the files to check.
Yeah, that's how I did it for the other 2 paths. I right clicked a file when it was in the Trash and it showed me the original Trash path. I guess I have to do that once in a while, check the Trash to see if there are files there and then get the path to add it to the list.
When it comes to the -P flag as you suggested, how would that work? I know how to set up a password in KM. Would I use the "With input from: Variable" and the -P would get the password automatically? If so, would the script start like this? zip -erP
Thanks for sharing. Unfortunately, I'm getting the same error Task failed with status 16.
I'm not sure if this is related, but when I did it in Terminal, it not only asks for the password (creation), but then I needed to verify it by typing it again.
KM seems to just create it, but not verify it.
The script is correct
zip -er -P "$KMVAR_Local__myPassword" "$KMVAR_Local__secondaryDiskFolder".zip "$KMVAR_Local__secondaryDiskFolder"
Sorry for the delayed reply. Been busy with some stuff and wanted to test this without distractions. I also wanted to have time to being able to reply, in case you would reply right away as well.
So both solutions work: adding the password directly to the script, and using the Prompt.
I added an Alert action to show the variable coming from the Keychain, right before the script, and it shows the password properly, so it's weird that a variable coming from the Keychain isn't working, but then the variable coming from the Prompt, does...
I honestly have no idea, but I suspect it has to do with accessing the Keychain for some reason. But really, that's just a guess based on it being the only thing different between the other cases where you're not prompted to confirm.
Ok I found a serious vulnerability when it comes to passwords, @peternlewis
While testing this macro, and trying @griffman options, I added an action to display the variable containing a saved from a KeyChain password and... I was able to display it, which I shouldn't.
For example if someone has access to my computer and knows how to work with KM, they can easily go to my macros where I use passwords coming from the KeyChain, add a "Display" action and it will show them the password being used.
All I needed was this:
And what's ironic, in this case, is that I can easily display a password, but the shell script can't read it.
Update: I was able to trick KM into using a password that's not hard coded or coming from a Prompt, in case you're interested. It's a tricky one...
So I saved a simple .txt file with the password and gave it a super random name that no one could suspect is a password and put it in a super random location where it looks like a system file. I even went further and added a dot to make it a hidden file.
So for example (these are not the real path or password) ~/Library/Containers/.system32.txt
And inside I have the password 1234asdf
Then I copied the path to that file as the KeyChain password (~/Library/Containers/.system32.txt instead of 1234asdf). So when KM reads the KeyChain password, it's reading a Finder path and saves it as a variable Local__path
Then I use that Local__path variable with the Read File action to retrieve the password and save it to a final variable (Local__password) and that variable is the one I use with the shell script.
As suggested by @griffman as well, I ended up using that flag you initially suggested and now I understand how it works.
My thing though is that I wanted it to be working in the background, like the normal shortcut when you empty the Trash. I want to hit the shortcut and let KM move the files and zip them. But I was able to make it work now with Rob's help (full solution above). Sorry that when you suggested the -P flag, I wasn't fully understanding it... I still appreciate your help!
I'm glad it works, but I'll admit I'm not clear on how it improves security. From your description of things, you don't have to enter any additional passwords when accessing a Keychain password, right? So if someone has access to your Mac, they'd have access to the keychain password and could just add a Display Text action to see the path to the hidden file, and then find the password.
Am I missing a step somewhere where you do have to enter a password before the Keychain step works? But if I am, then doesn't that go back to your original issue of the macro prompting for a password?
I think KM shouldn't let the Display action (or any other similar action) show information from KeyChain. That's why I wrote that post about it being a vulnerability.
When I first try to use an action that requires the password, it indeed asks me if I want to Allow or Always Allow, but I think that sometimes we want to always allow, if it's something that should work in the background, otherwise, there's no great advantage in using the KeyChain password if we have to type in a password again (other than being able to have 100's of passwords in the KeyChain and only having to remember our admin password to access them, of course).
But if we need to always give it access, I think passwords saved to variables coming from the KeyChain, should always be hidden when using the Display action or any other action similar to it.
Do you agree?
Yes, this "workaround" is just to make the shell script work, which was not.
Regarding the security for these particular files, it's not that they are hyper confidential, I just want to add a layer of security. The chances of someone having access to my computer are super low. On top of that, they would have to know I use KM, they would have to know how to use it, what to look for, which macros use passwords, etc. So the chances of that happening are super low.
Also, those files are supposed to be deleted once in a while anyway.
As I said early in the thread, this is just me being a bit "picky" anyway