dansherman

@davewripley, I think we're having the same problem. In my case Alfred can see things stored in Dropbox that I've worked on recently, and some other random bits, but not most of the older stuff. If I search in the spotlight pop-up (the default cmd+space) I can find any file on the computer, even if Alfred can't. I rebuild the metadata and things work fine for a little while (hours, maybe days), but then its "long-term memory" goes away. Do you have houdahspot? It's another frontend for spotlight that gives some really detailed file search options. It also has the same problem as Alfred, where it can only find a small set of the files stored in Dropbox. All that makes me think it's a spotlight/dropbox issue, but I haven't been able to figure out more than that.

I've been having similar problems since upgrading to Big Sur. The Spotlight GUI can find things, but its a little slow (that makes me think there is an indexing problem). If I use `mdfind` from the terminal my results are patchy, exactly like Alfred.

@Vero Things were great for a day or two but at some point the index seems to have been corrupted again and I'm having the same issue. I don't know if it's a Big Sur bug or something with Alfred, but I wanted to mention it here (for reference if nothing else). I'll re-index and see what happens.

Terminal was in the list of apps with Full Disk Access, but the box wasn't checked. I checked the box and ran the rebuild metadata tool again. This time there weren't any errors! Index is taking a lot longer this time so I assume it's working correctly (last time indexing was done in less than two minutes). Thanks for your patience!

Last login: Tue Jan 12 05:33:25 on ttys000 /Applications/Alfred\ 4.app/Contents/Frameworks/Alfred\ Framework.framework/Versions/A/Resources/reindexdel.sh ; exit; (venv-dan) ➜ ~ /Applications/Alfred\ 4.app/Contents/Frameworks/Alfred\ Framework.framework/Versions/A/Resources/reindexdel.sh ; exit; *************************************************** * * * This script will reindex your metadata by * * firstly deleting .Spotlight-V100 then * * running the command 'sudo mdutil -E -i on /' * * * * Indexing can take up to an hour * * and Alfred won't work during this time. * * * * You can see the progress of the reindexing * * by performing a search in Spotlight. * * * *************************************************** Close this window to cancel, or press any key to continue... Attempting to delete .Spotlight-V100... Password: rm: /System/Volumes/Data/.Spotlight-V100: Operation not permitted Requesting metadata reindex... /: Indexing enabled. You can see the progress of the reindexing by performing a search in Spotlight Press any key to finish... Saving session...completed. [Process completed] I did rebuild the index and checked the V100 box. Looks there was an error deleting the V100. Do you have any suggestions on manually deleting it?

I've done some more digging and running `mdfind -onlyin /Users/dansherman/clients -name Forms` also does not find the Forms folder. Actually, using `-onlyin /Users/dansherman` doesn't find it either. Even running `mdfind . -onlying /Users/dansherman/clients` only returns files and folders I've opened since upgrading to Big Sur. Which is useful in a way, but not most of the time. Chalk this one up to a Spotlight bug I guess?

I re-rebuilt the index and it still doesn't work. I'm specifically trying to find a folder, but searching for a file gives the same result. This happens in the default File Search as well as with File Filters in workflows. Other files and folders in this parent folder show up just fine if I've opened it since upgrading to Big Sur. This is the Alfred Metadata Tool result for a folder that does not show up in Alfred but does in spotlight: /Users/dansherman/clients/Forms Internal File Metadata ====================== Display Name: Forms Alt Names: File Type: public.folder Comments: Keywords: Last Used: 2020-10-23 12:58:42 +0000 Raw mdls File Metadata ====================== _kMDItemDisplayNameWithExtensions = "Forms" kMDItemContentCreationDate = 2018-11-14 19:10:34 +0000 kMDItemContentCreationDate_Ranking = 2018-11-14 00:00:00 +0000 kMDItemContentModificationDate = 2020-10-23 12:58:42 +0000 kMDItemContentModificationDate_Ranking = 2020-10-23 00:00:00 +0000 kMDItemContentType = "public.folder" kMDItemContentTypeTree = ( "public.folder", "public.directory", "public.item" ) kMDItemDateAdded = 2020-04-16 21:15:29 +0000 kMDItemDateAdded_Ranking = 2020-04-16 00:00:00 +0000 kMDItemDisplayName = "Forms" kMDItemDocumentIdentifier = 0 kMDItemFSContentChangeDate = 2020-10-23 12:58:42 +0000 kMDItemFSCreationDate = 2018-11-14 19:10:34 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = (null) kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = (null) kMDItemFSLabel = 0 kMDItemFSName = "Forms" kMDItemFSNodeCount = 35 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = (null) kMDItemFSTypeCode = "" kMDItemInterestingDate_Ranking = 2020-10-23 00:00:00 +0000 kMDItemKind = "Folder" kMDItemLastUsedDate = 2020-10-23 12:58:42 +0000 kMDItemLastUsedDate_Ranking = 2020-10-23 00:00:00 +0000 kMDItemUseCount = 2 kMDItemUsedDates = ( "2020-08-04 05:00:00 +0000", "2020-10-23 05:00:00 +0000" ) Is there any other information I can provide?

I've rebuilt my index a few times, spotlight can find files just fine, and the Alfred Metadata Tool shows the correct info, so I *think* that means this is an Alfred issue. The File Search and File Filter in a workflow will only find files and folders that I've opened since installing Big Sur. If I haven't opened it, Alfred can't see it. I tried clearing Alfred's learning knowledge, but that didn't make a difference. Any other ideas?

Sounds great, thanks!

I'm not sure if this is a bug, or by design. But it feels buggy to me, so I thought I'd post it here. In the "Advanced" tab I set `cmd + return` to "Search with Spotlight". This works as expected in a vanilla Alfred query, but if I do a file search it changes from "Search with Spotlight" to "Find similar files". I'd expect it to perform a spotlight search with my query instead of showing me related files. Latest Alfred 2.0.7(205), OSX 10.8.4

I updated add.scpt to work with any track in iTunes (in my library anyway — including iTunes Match tracks located in iCloud). on run argv set sArgv to argv as text tell application "iTunes" set myList to sArgv set current_track to the current track set sTrack to name of current_track set sArtist to artist of current_track --check if in playlist set sListTracks to name of tracks of playlist myList as list if sListTracks contains sTrack then return "\"" & sTrack & "\"" & " is already in " & "\"" & myList & "\"" else set currentList to playlist myList duplicate current_track to currentList return "\"" & sTrack & "\"" & " added to " & "\"" & myList & "\"" end if end tell end run

Well, that pretty much takes care of my suggestion. Thanks.

I've done that, and it works ok, but I think it'd be even better if Alfred could replace the existing text directly. Especially without involving the clipboard or defining a new hotkey.

I'd love to be able to select some text, pull up Alfred, type a keyword, and run a script to manipulate the selected text. A lot of this can be done through text services, but it'd be great to do it straight through Alfred. I suppose another way to do this would be to call the separate service from within Alfred. Either way, it would be nice to return some manipulated text.

All set. I added a line to replace 'https' with 'http'. The link in the first post has the updated version.