cbowns Posted July 20, 2017 Share Posted July 20, 2017 One of my most common Alfred actions is moving things from ~/Downloads to different folders. An especially common case is moving an application I download (usually decompressed from a .zip) to the /Applications folder. I've set up a new MacBook Pro from scratch and have been using Alfred to copy apps to the Applications folder, and have seen one particularly weird thing with all the applications I've had Alfred move there: they all report some variant of the same error when launching or doing their Sparkle self-update check, saying "I'm on a read-only volume, so updating won't succeed". Has anyone else seen this? Is this macOS being weird, Alfred being weird, (some weird xattrs being set? probably… ), or is something else responsible? (I've fixed it by manually copying the applications to my Desktop, deleting the copy in /Apps, and moving it back via drag and drop.) My config: - 2017 MacBook Pro - Alfred 3.4 - macOS Sierra, 10.12.6 Link to comment
deanishe Posted July 21, 2017 Share Posted July 21, 2017 It sounds like option (a): macOS being weird. Alfred doesn't mess about with your volume settings, and you'd have to authorise (as an admin) changing a volume to read-only in any case. Link to comment
cbowns Posted July 21, 2017 Author Share Posted July 21, 2017 Ah ha, found the answer. It's because of Apple's new translocation feature: only an application which is *dragged* by the user to /Applications (i.e. not `mv`ed by a shell script) will clear a read-only bit which is set on the app bundle. https://github.com/potionfactory/LetsMove/issues/56 Link to comment
Andrew Posted July 21, 2017 Share Posted July 21, 2017 @cbowns not sure if you spotted in that thread, but you can remove the quarantine flag with xattr after the mv, and then the app won't be translocated by macOS. Link to comment
cbowns Posted July 21, 2017 Author Share Posted July 21, 2017 @Andrew Yeah, I tried that in testing. I've gone back to just moving the apps myself. I was gonna make a post for this Bug Reports to see if Alfred could do that in the move, but I'll leave it up to you if you think it should or not. Link to comment
Andrew Posted July 21, 2017 Share Posted July 21, 2017 @cbowns try doing an xattr -rc /path/to/app to remove all extended attributes before copying it to /Applications. This should work absolutely fine, and something I've been doing for quite some time with various things. Interestingly, a while back, I started deploying Alfred in a signed dmg instead of a zip, as recommended by Apple - Apps packaged inside a signed dmg are not translocated by macOS. It's unlikely Alfred's move command will remove the extended attributes, as it would sidestep a default feature added by Apple. Cheers, Andrew cbowns 1 Link to comment
Andrew Posted July 21, 2017 Share Posted July 21, 2017 ... it's also worth noting that it would be super simple to create a workflow which adds a File Action for "Move to Applications", set for type Applications only. This could be a super simple script which removes xattrs and moves to /Applications/ Cheers, Andrew cbowns 1 Link to comment
johnnynoble Posted October 24, 2018 Share Posted October 24, 2018 Another note on this, some apps -- Little Snitch, in my example -- have issues with Translocated apps. It can't set firewall rules for the app because it looks like each launched instance of the app is actually a temporary copy of that app. I just have to remember not to use Alfred to 'Move to... /Applications' when I have an app in my Downloads folder. No big deal, but it would be great if Alfred either a) warned me, b) moved it properly, or c) just flat-out refused to move the file. Link to comment
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