aaronsurrain

Trying to get here: /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/ ...I search for "IFFB" but do not get the direct match. Instead I only get subfolder results like... /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/Notes/2015... /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/Notes/2015... /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/Notes/2015... /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/Notes/2015... /Volumes/Secomba/main/Boxcryptor/Dropbox/e/GLS/Clients/IFFB/Notes/2015... I would pick one of them and go up directories until I get to the folder I want but it happens with many different searches. Also, I don't want to teach Alfred that I like these subfolders. I don't know why they are showing up. Thanks! Aaron

-- NORMAL -- Andrew, Thanks for weighing in. I think I understand what you're saying, but I can't reconcile it with my understanding. If globally registered hotkeys take precedence over application keyboard shortcuts like finder, then I would think an application that is blocking Alfred from hearing the key press would also block finder from hearing it. How would a conflicting process hear the key press, do nothing itself, then pass it down the chain in such a way that it skipped Alfred but not skip the lower priority application? It just seems to me like Alfred is not successfully registering hotkeys for workflows. I haven't gotten through Vero's instruction to quit processes until Alfred works again. I'll be working on that next. Thank you, Aaron

I have new information that might help. The hotkey I'm trying to use is control+command+T which, when I have finder open, works for finder. It adds the current folder to the sidebar. When I created a new account on my mac and made the same hotkey, Alfred recognized it. The same conflict existed on the new account, but Alfred prevailed. But on my primary user account, Alfred is no match for finder. In our last exchange, it was suggested that I have another hotkey conflict, but I think this demonstrates that I do not because that conflict would have also intercepted my hotkey before finder could get it. Finder is getting the hotkey that Alfred should be intercepting. Any other ideas would be greatly appreciated. Thank you, Aaron

-- NORMAL -- I have tried many different hotkey combos. Hooking the hotkey to a bash script also didn't help. Removing the app and dragging it on, as well as trying many different apps didn't help. Is there a log I should send someone or pick at myself? Is there any way to systematically see where it's failing? Thanks! Aaron

Here's a link to 4 screenshots on DropBox. https://www.dropbox.com/sh/6ilavys13amyiap/AAB570R3PE5I2R9hqrRzKDHfa?dl=0 Thanks! Aaron -- NORMAL --

Thanks! My attempts to upload png screenshots are met errors. If there's another way to share a workflow, can you walk me through it or direct me to instructions?

Thanks for the ideas of things to check, but they were all set as you advised and it's still not working. Argument is none, HotKey box is connected to Launch Apps/Files, and HotKey action is Pass Through to Workflow. Sorry about my delayed response. Either I missed the email or I didn't know you have to follow conversations your start, which I did now so I should be quicker to reply. Thanks again, Aaron -- NORMAL --

I can't get a simple workflow with a Hotkey (^⌘T) and a Launch Apps/Files (iTerm) to work. When I type the hotkey it fails silently. The one exception seems to be that if I type the hotkey when I'm in finder and no finder window has the focus, the OS dings as it would had I typed any unassociated hot key (⌘V, for instance). In Alfred preferences I have tried many other hotkey character combinations, changed the argument and passthrough settings, linked it to other apps, and watched the debug window but nothing seems to affect it and nothing appears in the debug window except for the default text: Starting debug for 'Apps'. I have another computer that is set up similarly to the computer I'm having trouble with and am having the same trouble. I could use any tips on troubleshooting basic stuff like how to see if (and which) other apps are conflicting with Alfred or if there is a more general log for Alfred that might have a clue about what's going on. Thank you, Aaron -- NORMAL --

Something worked. Thank you. I wouldn't say the privacy thing is pointless because it gave immediate feedback where reindexing the whole thing gave me none. Without feedback, I have no way of knowing if something silently killed the process. I do appear to have lost history knowledge--Alfred's learning--of my usage with the reindex. When I search for "IFFB" Alfred offers results of files and folders in the IFFB folder but not the actual IFFB folder which seems weird. You'd think an exact match would be a top result--at least higher than children of an exact match. After going to the folder in finder and opening it, it now appears as a top result. I do think this is a bug. If Alfred is case-agnostic, changing the capitalization of part of a path should not require a reindex and the loss of history. I'd be curious to hear the position counter to that. Thanks again! Aaron -- NORMAL --

I tried the 3 recommendations from Vero and they did not help. I didn't see a way to determine whether or not step 2 was completed successfully. I couldn't find a way to check the progress. I just got the 2:59 post from deanishe and tried dragging the parent directory of the problem directory to Spotlight's privacy pane and that removed all results related to my problem search. I removed it and it has yet to reappear if Alfred's results. I hope I don't lose all of Alfred's learning by doing this. I'm still a little bit hung up on the idea that Alfred can't open a path if the capitalization is incorrect. I'm missing how that makes sense if Alfred is case-indifferent. Thanks again for your help Vero and deanishe. -- NORMAL --

Restarting didn't help. I'm on step two of Vero's instructions. I'll check in again when it's done or in a few hours since I can't tell that it's doing anything.

-- NORMAL -- Thanks. I'll try what you suggest. The reason I thought it was a bug is because it seems like Alfred should be able to open a folder if the capitalization is off if it has no concept of case sensitivity.

Reliably—with caveats detailed below—when searching for a directory in Alfred 2.8.2 for Mac OS X El Capitan 10.11.3 (15D21), capitalization discrepancies between the actual path of the target and the path of the target as stored in the index (or at least as displayed among the search results be Alfred) cause Alfred to open the directory of the parent of directory that has the capitalization discrepancy instead of the target directory. Here is an example: This first path exists... /Volumes/Boxcryptor/Dropbox/e/GLS/Clients/IFFB ...and this second path is displayed as a search result for IFFB (see screenshot, note the capital B in DropBox)... /Volumes/Boxcryptor/DropBox/e/GLS/Clients/IFFB ...but hitting return opens this third path... /Volumes/Boxcryptor ...unless I leave the Finder window with the bad result open and search again immediately, in which case I will get the correct result. Also, sometimes if many windows are open (perhaps one of them displaying the "third path" above, I haven't checked) I can get the right result. In this case, I can close all open Finder windows, search "IFFB" again, and reliably induce the bug behavior. Thanks, Aaron P.S. I tried to include screenshots but got the error "You are not allowed to use that image extension on this community" when I pasted in screenshots and I didn't see a way to just add an attachment that didn't ask for a URL and show up as a question mark in a box. -- NORMAL -- -- NORMAL --

My Dropbox folder, now Dropbox, used to be DropBox (note the "B"). When I search files in that folder they appear. The ones that appear with the old capitalization scheme (DropBox) take me to the parent directory of Dropbox--not the file I searched. Unexpectedly, searching the same thing and selecting the same result a second time will take me to the correct place. Alfred doesn't learn from this. A later search will cause the same problem. What is the least destructive way to correct the path in Alfred's index? Thanks, Aaron -- NORMAL --

I would like to request support for Boxcryptor. Boxcryptor does two things. It encrypts your cloud storage and gives you easy unencrypted local access by mounting a drive that shows you the unencrypted contents of your cloud storage. I added this drive to Alfred's index, but Alfred seems to ignore it. Alfred only returns results from the encrypted folders. Now when I search for files and folders using Alfred, most of my results are useless because it doesn't return the file I can use but it does return the file I can't use.