Get Alfred to wait at startup for preferences stored on a non-mounted volume

[JamieKeene]

Hi Alfred team,

 

I use Google Drive File Stream (https://support.google.com/a/answer/7491144?hl=en) to sync my Alfred preferences to my work Google Drive account. Rather than taking space on the hard drive, this creates a virtual file system (FUSE style) which presents all of my Drive data as a network mount and gets necessary files just in time.

 

Until recently this worked great, but unfortunately in the last couple of months I've been getting this error when starting my computer:

 

The error is correct – the volume isn't mounted yet – but it means I need to quit and then restart Alfred to get my saved / synced config.

 

Has something changed here? Or have I just gotten unlucky? And either way, please could you consider adding a wait here to allow the volume time to appear before failing? Or is there a workaround I should know about?

 

Thanks!

[deanishe]

16 minutes ago, JamieKeene said:

Or is there a workaround I should know about?

 

IMO, the proper solution (because it's designed for such cases) would be to use a Launch Agent with QueueDirectories or WatchPaths to (re)start Alfred when your GDFS volume appears.

 

[JamieKeene]

Thanks deanishe – just to clarify, are you suggesting that Alfred should add this LaunchAgent when the user adds a sync path? Or that I should write this myself?

[deanishe]

1 hour ago, JamieKeene said:

Or that I should write this myself?

 

This. I use LaunchControl to write and manage launch agents.

[JamieKeene]

Fair enough, thanks for the pointer!

 

Just as an opinion, I think my bug / FR stands, though – given that this error path exists, my (uneducated) guess is that it would be simple enough for the app to make this more resilient and so not require users to DIY. 

[deanishe]

20 minutes ago, JamieKeene said:

I think my bug

 

It's not a bug. You've set Alfred to start at boot but put its preferences in a location that may not exist at that time. The flaw is in your setup, not Alfred.

 

39 minutes ago, JamieKeene said:

it would be simple enough

 

But it isn't simple, I'm afraid. How should Alfred know if its prefs are going to re-appear or if they're gone for good and it should show the error dialog above? How long should Alfred wait for its prefs bundle to reappear? Should it refuse to work until it does? Or silently create a new, empty prefs bundle and use that until it does? That's probably a no-go, as it will lead to support requests from users wondering why Alfred has lost their preferences when it's actually their VFS software that's not working.

 

I don't think that this is something that Alfred can handle smoothly without causing other issues. And features that will cause issues (and therefore support requests) are effectively off the table.

[Andrew]

@JamieKeene I agree with Dean here, Alfred can't EVER know if that drive will exist at startup, which is why you get the warning message showing.

 

I'm going to move this into feature suggestions and change the title, as if it becomes a common problem, it might become something worth investigating.

[deanishe]

From what @JamieKeene said, it does at least sound like Google Drive has got better at syncing (Alfred's preferences).

[deanishe]

@JamieKeene Here's a Launch Agent that will run Alfred when your GDFS volume appears. Save it as ~/Library/LaunchAgents/alfred-gdrive.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>net.deanishe.alfred-gdrive</string>
	<key>Program</key>
	<string>/Applications/Alfred 4.app/Contents/MacOS/Alfred</string>
	<key>QueueDirectories</key>
	<array>
		<string>/Volumes/GoogleDrive</string>
	</array>
</dict>
</plist>

 

[JamieKeene]

On 11/8/2019 at 9:19 PM, deanishe said:

From what @JamieKeene said, it does at least sound like Google Drive has got better at syncing (Alfred's preferences).

 

I've not seen any issues until recently – hence raising it here. It looks like something's changed (I guess either in my machine's boot order, or in DriveFS) that now means it's slower to mount compared to the speed which Alfred expects it to be there, and so I'm seeing this error for the first time. Thanks for your response though, both

[_Sascha_]

I've the same issue, the external storage where Alfreds-Sync-Profile is located to, starts to late.

The reason is simple, the Storage keeps the folders for the cloud and is encrypted.

 

Means, when the user logins, the Mac decrypts the local files first.

Then it starts all Apps who are set up to start at the login and mounting the external devices.

 

The issue here is just simple, Alfred starts faster then the external SSD getting mounted. 😜

 

Workaround as long no feature to re-check location-exsistence is to use a:

 

• Script which just sleeps and starts your applications (simple bash)
• Launch Agent (what deanishe suggested, nice app he found by the way)
• App which you put into your applications at login which delay the start of other applications (see Google for this)

 

I will testing out now Startupizer 2, this looks like exactly what I need. It makes even the first setup easy, by allow you to move your startup-items into it and then setting up conditions. (mine are: Start Dropbox/Nextcloud when external drive appears and then Alfred has the same condition including waiting that both applications already running) Let's see how it works, if I don't write anything more here, it was fine. 

 

Edited October 16, 2020 by _Sascha_