Eric Moyer Posted August 24, 2023 Share Posted August 24, 2023 (edited) I discovered this by accident when I found that the "Simple Folder Search" workflow wasn't finding a folder called "data.nrc.4.0". I am running Alfred 5.1.2 (2145) I can reproduce the problem by creating a bunch of test folders with the name "fnord{ending}" (with various test endings) and then typing 'fnord into the Alfred search box (screen shot attached). All folders ending with ".{single_numeric_digit}" are reported as "files" (white icon) rather than "folders" (blue folder icon), which also means that the "Simple Folder Search" (fs) workflow (which only searches for folders) does not find them (screenshot attached). I wouldn't be surprised if the root cause were an Apple API issue; seems like a strange bug to be coming from Alfred's side of the stack but who knows? Thanks! Edited August 24, 2023 by Eric Moyer added another screenshot Link to comment
Eric Moyer Posted August 24, 2023 Author Share Posted August 24, 2023 I found another of the same class of problem. Alfred thinks folders ending in ".net" are files rather than folders. Link to comment
Vero Posted August 24, 2023 Share Posted August 24, 2023 @Eric Moyer Welcome to the forum Your best bet is to look at the metadata created by macOS for these files, which you can do by using the File Troubleshooter built into Alfred: https://www.alfredapp.com/help/troubleshooting/indexing/ This will give you insight into how macOS is classifying your files. Link to comment
Eric Moyer Posted August 24, 2023 Author Share Posted August 24, 2023 Spotlight is indexing the files, but is classifying the ".{single_digit}" and ".net" folders in some slightly different way, evidenced by the fact that spotlight lists them in a section called "Other" rather than listing them in the "Folders" section. I have reproduced that behavior on two different machines (the two attached screenshots). In both cases spotlight does show the item as a blue "folder" icon, and lists its type to the right as a "folder", so at some level spotlight knows (or figures out) that the item is the folder even though it has been classified as "other". It looks like the problem stems from the UDI types apple assigns to these folders. You can list the UDI type by running "mdls" on a folder; the UDI is the value listed as "kMDItemContentType" . The "weird" folders get assigned a UDI of the form "dyn.{some string of characters}", and those suffix characters are unique from folder to folder. If I manually add "dyn.*" to the the list of file types (in the Simple Folder Search workflow) then it DOES start to find those folders, though it still lists them with a white file icon instead of a blue folder icon. I ran out of space on allowed images so I will post those screenshots in another reply... Link to comment
Eric Moyer Posted August 24, 2023 Author Share Posted August 24, 2023 Here is a screenshot of adding "dyn.*" to the "File Types" list, and the search results after doing so. I don't know what the "dyn.{}" UDI means, or is for, in apple's ecosystem, and I don't know whether Alfred receives the necessary information (from spotlight) to figure out that these "dyn.{}" objects are really folders, but it may be possible. That would question would have to go to a developer who knows the spotlight API. Link to comment
Andrew Posted August 25, 2023 Share Posted August 25, 2023 What's happening here is by naming a folder with an extension, you're essentially assigning it a type in the underlying index. When the underling index doesn't have an association for that type, it assigns it a dyn.* type (which is a hash of the extension) as a placeholder until an app claims this extension. An example of this is if you rename a folder Something.alfredpreferences, this folder will get an Alfred icon and all of a sudden become a "com.runningwithcrayons.alfred.preferences" package, even though it's still a folder. Alfred leans towards the "correct" identification of the file rather than automatically treating it as a folder (which macOS can use as various other things). If you're looking at configuring a File Filter to find all folders, I wouldn't recommend adding dyn.* to the file types as this could make your file filter also include many other unassociated indexed files which aren't folders. The underlying content type tree in the metadata for all of these types includes "public.directory", so if you configure your file filter to be +public.directory, then this will match against the tree and find all folders. Link to comment
Eric Moyer Posted August 25, 2023 Author Share Posted August 25, 2023 Thanks @Andrew! That makes perfect sense. Perhaps I never should have started using dots in dir names, though I see Apple doing it too (e.g. `~/Library/com.apple.bluetooth.services.cloud`), and of course lots of config file management does it (e.g. `~/.ssh`). It never seemed like the OS clearly indicated it was bad practice, but perhaps it is. In retrospect I could avoid many of them by adopting different personal conventions. Below is the diagnostics dump for `fnord.1`, which is just a blank dir I created for testing (on Ventura 13.5.1 (22G90)). I don't see "public.directory" in the content tree (just `public.data` and `public.item`, and the `dyn.{}` entry), and (as one might expect, given that content tree) adding `+public.directory` didn't cause the Alfred's search to hit on this folder. I'm guessing `public.data` and `public.item` are both quite generic, so adding either of those is probably a bad idea. After that is the diagnostics dump for `fnord.01`, which has no `dyn.{}` and does have `public.directory` in addition to `public.folder`, so there is some funny business going on with Apple's content type assignments for specific patterns (like `.{single_numerical_digit}` and `.net`). Starting Diagnostics... File: 'fnord.1' Path: '/Users/eric/temp' ----------------------------------------------------------- Check file cache database... ✅ File cache integrity is ok ----------------------------------------------------------- Check if file is readable... ✅ Alfred has permissions to read this file. Unix Permissions: 493 Underlying Type: NSFileTypeDirectory Extended Attributes: ( ) ----------------------------------------------------------- Check if volume '/' is indexed by macOS... ✅ Indexing is enabled on this drive ----------------------------------------------------------- Check direct file metadata... ⚠️ Direct metadata available, but content type may be incorrect Display Name: fnord.1 Other Names: Content Type: dyn.ah62d4rv4ge8xc Last Used: ----------------------------------------------------------- Check mdls file metadata... ✅ Metadata contains required items _kMDItemDisplayNameWithExtensions = "fnord.1" kMDItemContentCreationDate = 2023-08-24 02:24:30 +0000 kMDItemContentCreationDate_Ranking = 2023-08-24 00:00:00 +0000 kMDItemContentModificationDate = 2023-08-24 02:24:30 +0000 kMDItemContentType = "dyn.ah62d4rv4ge8xc" kMDItemContentTypeTree = ( "public.item", "dyn.ah62d4rv4ge8xc", "public.data" ) kMDItemDateAdded = 2023-08-24 02:24:30 +0000 kMDItemDisplayName = "fnord.1" kMDItemDocumentIdentifier = 0 kMDItemFSContentChangeDate = 2023-08-24 02:24:30 +0000 kMDItemFSCreationDate = 2023-08-24 02:24:30 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = (null) kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = (null) kMDItemFSLabel = 0 kMDItemFSName = "fnord.1" kMDItemFSNodeCount = 0 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = (null) kMDItemFSTypeCode = "" kMDItemInterestingDate_Ranking = 2023-08-24 00:00:00 +0000 kMDItemKind = "Folder" ----------------------------------------------------------- Check file is in search scope... ✅ File exists within Alfred's default search scope ----------------------------------------------------------- Check MDQuery file search... ✅ macOS returned a match for this file in your search scope. File Search Results for search scope ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.1" ) File Search Results for ~/ ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.1" ) File Search Results for / ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.1" ) ----------------------------------------------------------- ✅ Troubleshooting passed ⚠️ There were 1 warning(s) Starting Diagnostics... File: 'fnord.01' Path: '/Users/eric/temp' ----------------------------------------------------------- Check file cache database... ✅ File cache integrity is ok ----------------------------------------------------------- Check if file is readable... ✅ Alfred has permissions to read this file. Unix Permissions: 493 Underlying Type: NSFileTypeDirectory Extended Attributes: ( ) ----------------------------------------------------------- Check if volume '/' is indexed by macOS... ✅ Indexing is enabled on this drive ----------------------------------------------------------- Check direct file metadata... ✅ Direct metadata available Display Name: fnord.01 Other Names: Content Type: public.folder Last Used: ----------------------------------------------------------- Check mdls file metadata... ✅ Metadata contains required items _kMDItemDisplayNameWithExtensions = "fnord.01" kMDItemContentCreationDate = 2023-08-24 02:09:52 +0000 kMDItemContentCreationDate_Ranking = 2023-08-24 00:00:00 +0000 kMDItemContentModificationDate = 2023-08-24 02:09:52 +0000 kMDItemContentType = "public.folder" kMDItemContentTypeTree = ( "public.folder", "public.directory", "public.item" ) kMDItemDateAdded = 2023-08-24 02:09:52 +0000 kMDItemDisplayName = "fnord.01" kMDItemDocumentIdentifier = 0 kMDItemFSContentChangeDate = 2023-08-24 02:09:52 +0000 kMDItemFSCreationDate = 2023-08-24 02:09:52 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = (null) kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = (null) kMDItemFSLabel = 0 kMDItemFSName = "fnord.01" kMDItemFSNodeCount = 0 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = (null) kMDItemFSTypeCode = "" kMDItemInterestingDate_Ranking = 2023-08-24 00:00:00 +0000 kMDItemKind = "Folder" ----------------------------------------------------------- Check file is in search scope... ✅ File exists within Alfred's default search scope ----------------------------------------------------------- Check MDQuery file search... ✅ macOS returned a match for this file in your search scope. File Search Results for search scope ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.01" ) File Search Results for ~/ ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.01" ) File Search Results for / ( "[0] /System/Volumes/Data/Users/eric/temp/fnord.01" ) ----------------------------------------------------------- ✅ Troubleshooting passed Link to comment
vitor Posted August 25, 2023 Share Posted August 25, 2023 1 hour ago, Eric Moyer said: (e.g. `~/Library/com.apple.bluetooth.services.cloud`), and of course lots of config file management does it (e.g. `~/.ssh`). To expand a bit on the technical aspects here, the former is a bundle identifier and the latter is a dotfile, the leading period makes it invisible. Link to comment
Eric Moyer Posted August 25, 2023 Author Share Posted August 25, 2023 36 minutes ago, vitor said: To expand a bit on the technical aspects here, the former is a bundle identifier and the latter is a dotfile, the leading period makes it invisible. Sure; the former is more or less true. The latter (~/.ssh) is a directory not a file, but it does follow the "dotfile" pattern because that pattern makes it invisible. My point in citing those examples was that because the OS uses dots in directory names I felt "justified" also using dots in directory names (though I'm likely to start avoiding it in the future). Also, Finder doesn't complain if you make a directory called "fnord.0", but it will complain if you try to make a directory called "fnord:0", which (whether Apple likes it or not) "teaches" that the former is acceptable and the latter is not. Apple may have a spec somewhere which say "please don't use dots in directory names", but because OSX allows it and Finder allows it I ended up adopting it. At the end of the day I'm not super hung up about this with regard to Alfred; adding "dyn.*" is a palatable workaround for me and perhaps I am an outlier in using dots in directory names. I do find it super curious that apple has unique UDI behaviors for ".{single_numeric_digit}" and ".net". Link to comment
TommyRot Posted May 4 Share Posted May 4 As a possible addendum to this topic, I was becoming increasingly frustrated not being able search for files that I knew to exist on my Mac (monterey). I had folders called, for example, 'Research, Snippets etc.' Nothing in these folders was showing up in the search results. Eventually, I got around to doing a spot of testing today and I discovered that folders ending in a dot / period are the problem. After removing the trailing dot, these appear again in results. I take it this is related to the discussion above. I wonder whether macOS/Alfred is expecting characters to follow the dot/period, but isn't able to handle the exception of there not being any. Anyhow, to be on the safe side, don't use dots/periods in folder names. 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