Ejectall command Quits the Alfred App [Fixed 3.8.1 b961]

[yeagerfan]

I am currently using a 2016 MacBook pro 15inch retina with touchbar running OSX10.14.3 and the Alfred App Version 3.8 build 959. 

 

I typically use the eject all command at the end of the day to eject several attached HD's before taking my laptop home for the night.  When I enter the command it ejects all the drive I need to eject and it also quits the Alfred app as well so that I have to either navigate to the applications folder or use the built in mac search to restart the app.  This has been constantly happening for 3 weeks now where it used to work just fine.  I have tried shutting down and restarting my computer several times, as well as clearing the application cache and rebuilding the MacOS MetaData.  When that did not work, I uninstalled the App and erased all the preference files I had and then reinstalled the app and it is still doing the same problem.  Hopefully I missed something easy and you all can help me.  If I can provide any other details please let me know. 

[Andrew]

@yeagerfan I have a fix in for this already for an upcoming 3.8.1 release - it's to do with a change in the way eject errors are being dealt with.

 

Cheers,

Andrew

[yeagerfan]

Thank you Andrew.  I have been pulling my hair out trying to figure this one out.  I will look forward to the update. 

 

Kurt

[deanishe]

23 hours ago, Andrew said:

it's to do with a change in the way eject errors are being dealt with

 

Any chance Alfred will say "blah is using the device" when eject fails?

 

Whenever it fails, I have to go to the terminal and use umount instead, as it tells you which program is blocking unmounting.

[Andrew]

@deanishe The error which is returned to Alfred after the NSWorkspace call only goes as far as Error Domain=NSOSStatusErrorDomain Code=-47 "fBsyErr: File is busy (delete)".

 

With a quick look, I can't see anything obvious to get more info within the API, but I'll make a note to look into this when I get a bit more time.

[deanishe]

I've had a play in, umm, a Playground, and FileManager.unmountVolume gives you an error that contains the PID of the process blocking the unmount.

 

Finder appears to do some additional jiggery-pokery to find the parent process (it says "iTerm2" is using the volume, but I'm getting the PID for zsh), but that's over my head.

 

Edited February 27, 2019 by deanishe

[Andrew]

@deanishe hmmm I seem to remember there was a reason I used the NSWorkspace method instead of NSFileManager one, but can't find anything in my notes. It may have been a legacy thing... To be honest, until you said that, I had forgotten that NSFileManager even had an unmount method!

 

I'll have a bit of a dig

 

Edit: Aha... that method is newer than I thought, macOS 10.11+, so it's more tricky to include as Alfred 3 supports older versions than this.

 

Cheers,

Andrew

[Andrew]

@yeagerfan if you update to the latest 3.8.1 pre-release, this is now fixed