Workflow Cache Dir, how and/or who has to create the Dir

[Acidham]

I tried to use Workflow Data Directory in Applescript combined with Bash (echo $alfred_workflow_cache) but when I use it the directory is not there. Bundle Id was set before. 

 

"Who" and/or "How" will the data directory be created? From Alfred automatically when Bundle ID is set or is it required that I have to create it manually/with the script?

[vitor]

You have to create it yourself. That variable is just that: a variable. It contains the information (in this case, the path to a directory), but you are the one who decides what to do with it.

[Acidham]

This means I need to script my workflow to check if the directory is available if not I need to create the directory? Furthermore I need to know what the bundle ID is or hardcode the directory creation with bundle ID?

 

I expected that the workflow cache dir will be created once Bundle ID was set :/ 

[deanishe]

You need to know the bundle ID/paths in any event simply in order to use the directories.

 

Not sure how I feel about Alfred auto-creating them. On the one hand, it'd be handy to workflow authors. On the other, you'd end up with an awful lot of unneeded, empty folders.

[Acidham]

...and on the other hand you need to add to the scripts a check if directory is available which will be executed every time you use the WF. I think # of directories it not an issue. 

[vitor]

6 hours ago, Acidham said:

...and on the other hand you need to add to the scripts a check if directory is available which will be executed every time you use the WF.

 

[[ -d "${alfred_workflow_data}" ]] || mkdir "${alfred_workflow_data}"

On my machine that takes (according to time) 1 millisecond after the directory exists (3 to create it). I’m not even sure it takes the full millisecond (can time display lower?). It’s also a single clear line.

 

6 hours ago, Acidham said:

I think # of directories it not an issue. 

 

I do not want a barrage of empty directories. I like to know when a workflow needs those directories or not. Not having a bunch of them also helps when diagnosing workflow problems or migrating them from one Alfred version to the next (like I did with some workflows I used that were abandoned in version 2).

In addition, there’s no scenario where Alfred could just create the directories once you open the workflows, because there’s always the possibility the user (or something on their machine) would delete them, meaning Alfred itself would need to always do that check. It might save a single line in your code, but it won’t save in execution time. In fact, it would mean that now every workflow that does not need those directories would also be constantly checking for those directories, which is even more wasteful.

Best we could expect here would be a toggle in the workflow creation sheet to tell if Alfred should create the directories or not, on a workflow-by-workflow basis. Not sure that is even worth it, but it wouldn’t be harmful either (although it might be confusing to some users).

[Acidham]

Ok, Thx a lot. I implemented it in my workflows with bash mkdir -p ....

[vitor]

33 minutes ago, Acidham said:

Ok, Thx a lot. I implemented it in my workflows with bash mkdir -p ....

 

mkdir -p is slower than the command I showed before in every case (initial creation and subsequent tries) and doesn’t get faster after the directory is created.

Edited January 26, 2017 by vitor

[Acidham]

OK implemented

[deanishe]

To be honest, I always use mkdir -p (or equivalent).

 

It's slower, but only hundredths of a second, and arguably more correct (for example, a workflow with Alfred 2 paths hardcoded will still work on Alfred 3, even though Alfred 2's directories don't exist.

 

If you just use mkdir, it will fail. 

[vitor]

@deanishe I think we might all be referring to slightly different things, with the last comments.

 

Yes, you can always do

[[ -d "${alfred_workflow_data}" ]] || mkdir -p "${alfred_workflow_data}"

Which is only slower on the first run, but would still cover every base and is equally as fast as my first command when the directory already exists (since the second command is skipped).

 

My impression of @Acidham’s previous comment was he was just doing

mkdir -p "${alfred_workflow_data}"

without checking for the existence of the directory.

 

I’d say however you do it -p or not, checking for the existence of the directory beforehand is more correct (though the matter is mostly theoretical once you remove speed from the equation) and objectively faster.

 

Having hardcoded paths is, I feel, a completely different discussion.

[deanishe]

1 minute ago, vitor said:

I’d say however you do it -p or not, checking for the existence of the directory beforehand is more correct (though the matter is mostly theoretical once you remove speed from the equation) and objectively faster.

 

Arguably, the "proper" way to do it is to go ahead and try to create the directory and handle the error if it fails because it's an atomic operation. Checking first for existence and then creating the directory isn't atomic, and it's possible (though extremely unlikely) that another process might create the directory after the check for existence and before the creation call.

 

Hardly relevant in a workflow, but check-then-create is a race condition that has led to exploits.

 

2 minutes ago, vitor said:

Having hardcoded paths is, I feel, a completely different discussion.

 

It is, but not unrelated. My decision to use the equivalent of mkdir -p in Alfred-Workflow means that workflows written back before Alfred got environment variables (i.e. when paths had to be hardcoded) still work on Alfred 3 (even if they write their data to the wrong directories). Workflows only doing mkdir broke for anyone who deleted (or didn't have) Alfred 2 directories.

 

(FWIW, it's always tested for the existence of the directory first, too. Privilege escalation via race conditions aren't a big worry for AW.)

 

[vitor]

1 hour ago, deanishe said:

it's possible (though extremely unlikely) that another process might create the directory after the check for existence and before the creation call.

 

(…)

 

My decision to use the equivalent of mkdir -p in Alfred-Workflow means that workflows written back before Alfred got environment variables (i.e. when paths had to be hardcoded) still work on Alfred 3 (even if they write their data to the wrong directories). Workflows only doing mkdir broke for anyone who deleted (or didn't have) Alfred 2 directories.

 

I get that, but again, my point was never about using mkdir over mkdir -p. My point was about checking for the existence of the directory and then creating it (-p or not) versus only doing mkdir -p without checking for existence.

 

So my point isn’t related to -p in mkdir, it is entirely related to [[ -d … ]].

[deanishe]

I know. I just thought that might be an interesting data point regarding -p versus non--p.

 

My main point was that there are arguments either way concerning whether you should test for the existence of a directory before creating it.

 

Having thought about this a bit, I think it'd be useful if Alfred had some kind of cleanup feature to purge data belonging to uninstalled workflows. A workflow could probably do it, but I can't think of a good way to fit it to Alfred's UI.

[vitor]

11 minutes ago, deanishe said:

Having thought about this a bit, I think it'd be useful if Alfred had some kind of cleanup feature to purge data belonging to uninstalled workflows. A workflow could probably do it, but I can't think of a good way to fit it to Alfred's UI.

 

Big thumbs up to that.

 

As to how to do it, when you delete a workflow via the GUI Alfred asks you if you’re sure. It could have an option there to delete the directories.

[deanishe]

That's a good start, but I don't think I'd always want to delete the workflow's configuration etc. immediately. You know, kinda like apt-get uninstall vs apt-get purge?

 

Perhaps Alfred could auto-delete a workflow's cache directory on uninstall and its data directory if its empty?