yeagerfan Posted February 25, 2019 Share Posted February 25, 2019 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. Link to comment Share on other sites More sharing options...
Andrew Posted February 26, 2019 Share Posted February 26, 2019 @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 Link to comment Share on other sites More sharing options...
yeagerfan Posted February 27, 2019 Author Share Posted February 27, 2019 Thank you Andrew. I have been pulling my hair out trying to figure this one out. I will look forward to the update. Kurt Link to comment Share on other sites More sharing options...
deanishe Posted February 27, 2019 Share Posted February 27, 2019 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. Link to comment Share on other sites More sharing options...
Andrew Posted February 27, 2019 Share Posted February 27, 2019 @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. Link to comment Share on other sites More sharing options...
deanishe Posted February 27, 2019 Share Posted February 27, 2019 (edited) 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 Link to comment Share on other sites More sharing options...
Andrew Posted February 28, 2019 Share Posted February 28, 2019 @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 Link to comment Share on other sites More sharing options...
Andrew Posted March 4, 2019 Share Posted March 4, 2019 @yeagerfan if you update to the latest 3.8.1 pre-release, this is now fixed Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now