The Finder can display more information about files than their size and datestamps, and for some types of file can extend to a lot of useful metadata. These are shown in the Preview pane containing the file’s QuickLook thumbnail, in the Get Info dialog, and some can be added to the columns shown in List View. This article explains where those come from, and how you can customise what the Finder displays.

Metadata collection

Within a second or two of a new file being created, or an existing file being saved, Spotlight’s indexing services analyse that file and extract both metadata and, where possible, content to be added to that volume’s indexes. Metadata that is common to most or all files, including datestamps, and the contents of any extended attributes, that might include titles and keywords, is indexed separately from that extracted from a file’s contents.

In between those are metadata embedded in file data. They’re specific to certain types of file, for example EXIF metadata that is commonly included in images, so are extracted by the specialist mdimporter for that file type, then incorporated into the indexes on that volume.

Finder display

When you select an item in a Finder window showing the Preview pane (typically in Column View), two chains of processes are started. One calls on QuickLook to return the thumbnail to be displayed in the upper section of the Preview pane, the other starts a metadata query at a high Quality of Service (25, userInitiated), which is passed to SpotlightServer, and access to that data is checked by TCC. Once approved, the metadata is returned from Spotlight to the Finder to populate the Information section below the thumbnail.

Information displayed in the Preview pane depends on that available in the indexes, the type of file, whether the list is set to show more or less, and the Finder’s settings in its Show Preview Options command in the View menu. That displayed in a Get Info dialog undergoes similar processing, to populate its More Info section in particular, although those don’t appear to come with any options.

Preview Options

To a degree, the user determines which fields are displayed in the Information shown in the Preview pane, although Apple doesn’t mention the key setting involved. Select the file, ensure the blue text to the right of Information is set to Show Less, then open its Preview Options using the Finder’s View menu.

Here are my current Preview Options for all Image files, which only include a single item from EXIF metadata, the Content Creator (which is duplicated in the list of options). While that window is open, those are the only items shown in the Preview pane.

When that Preview Options window is closed, the Finder immediately reverts to its comprehensive list, including many of those in the EXIF metadata, until you click on Show Less.

It’s only when the Preview pane is showing less information that your Preview Options are applied, and they’re now used the same for all types of Image.

These are the extensive Preview Options for this CorelDRAW document with a cdr extension, although here they’re claimed to be for a file archive because of a clash in extensions. This list is derived from the mdimporter provided, and correct for CorelDRAW files. Unfortunately, this window is too tall to be accommodated on the display, and doesn’t scroll.

When set to show more information, all non-empty fields appear in the list.

With less information showing, the list conforms to that set in its Preview Options.

To confirm the list of metadata, we can usually inspect what Spotlight should have indexed from that file.

Discovering metadata

In Terminal there are two ways to list the metadata for a file. The first is to interrogate Spotlight with the command
mdls filename
which should list all attributes with their values, except indexed content such as text tokens.

The other method using mdimport does something subtly different. Enter the command
mdimport -t -d2 filename
for a file with the path and name filename, and you’ll either see a long list of all its Spotlight metadata, or the command will crash. Although it’s easy to mistake this for the metadata stored in Spotlight’s indexes, it’s actually what should be stored there when that file is processed by the mdimporter named in the output. Its occasional crashes are a mystery, though, as it used to be reliable up to and including macOS Sonoma.

If there are metadata missing from mdls and mdimport‘s output and not shown in the Preview Pane when listing more information, you can only presume that they’re missing from Spotlight’s indexes, so won’t be discoverable in a Spotlight search.

Conclusions

• The Finder populates the information in its Preview pane from the file’s metadata in that volume’s Spotlight indexes.
• When showing more information, the list should include all non-empty metadata appropriate to that type of file.
• The Finder’s View Options customise what’s shown for all files of that type when there’s less information being shown.
• Use mdls to check those against metadata stored in Spotlight’s indexes, and mdimport is also helpful, if it doesn’t crash.
• If metadata are missing from the Preview pane, mdls and mdimport, they’re likely to be missing from Spotlight’s indexes as well, and are unlikely to be discovered by Spotlight search.

In the early years of this blog, I used to keep track of some of the more serious bugs in macOS. As that developed into what would have occupied me full-time, I’ve cut back to try to cover some of the most significant. What has surprised me with macOS 26.1 is the sudden rush of new bugs in an update that’s normally expected to fix more than it creates. To consider what might have gone wrong, here’s an overview of those I’ve been investigating so far.

macOS virtualisation (new in 26.1)

A macOS 26.1 guest assigns itself a serial number of zero for the VM, whether the VM has been installed from the 26.1 IPSW image file, or updated from a previous version of macOS. This results in features that rely on the VM’s serial number to fail, the most important being access to iCloud.

Further details.

Virtualisation is exceedingly complicated, and has suffered some previous accidents, such as the inability of M4 hosts running macOS 15.1 to virtualise guests with macOS earlier than 13.4. Although it’s easy to claim that better testing should detect these problems, the number of combinations of host Mac and macOS, and guest macOS increases their risk. Perhaps Apple should actively encourage third-party beta-testing in VMs.

Accessibility (new in 26.1)

macOS 26.1 introduces a new Appearance setting for Liquid Glass, but Apple hasn’t mentioned any change to the existing Reduce Transparency setting in Accessibility. However, that setting in 26.1 no longer disables Liquid Glass effects in sidebars and toolbars as it does in 26.0. User documentation for 26.1 is identical to that in macOS 15:
Make transparent items solid
Some windows and areas of the desktop, such as the Dock and menu bar, appear transparent by default. You can turn these transparent areas a solid grey to make it easier to distinguish them from the background.

This can be seen in the following screenshots.

This is 26.0 without Reduce Transparency.

This is 26.0 with Reduce Transparency turned on. Both the navigation sidebar and the window toolbar are completely opaque, and their contents are fully readable as a result.

This is 26.1 with Reduce Transparency turned on. Although the tools themselves are on opaque backgrounds, other areas remain partially transparent, and the toolbar in particular is visually cluttered and impairs accessibility.

Although this could be claimed to be intentional on Apple’s part, one visual feature that now appears when Reduce Transparency is turned on is the unreadable mess at the top of the System Settings window, where its search box overlays scrolling content in that sidebar.

If that’s intentional on Apple’s part, then macOS 26.1 is unsuitable for users with most forms of visual impairment, and many without.

Finder (new in 26.1)

In some Finder views, such as Column View, selecting an item at the left displays that item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

Further details.

This is a strange bug, as it doesn’t occur in macOS VMs, suggesting there’s something more complicated going on. However, it’s also obvious, easy to test, and should never have survived into a release version of macOS.

Clock (macOS 15 and 26)

In macOS 15 and 26, including 26.1, the Clock app offers Timers that are implemented using the mobiletimerd service. The latter appears to hoard every past timer in its property list until that grows too large for the service to run, following which the feature fails to function.

Further details.

According to Apple Support, an earlier bug in the mobiletimerd property list was fixed in macOS Sequoia. However, Apple is apparently unaware of the current problem. The current behaviour of mobiletimerd appears to be the result of poor design: if a service keeps adding more items to its property list, that will grow unconstrained, and sooner or later will cause this problem. It’s possible that fixing the previous bug may have resulted in the introduction of a new bug. Either way, this should have been detected long before it was released to the public.

Spotlight indexing (macOS 10.14 and later)

Since macOS Mojave, plain text files starting with certain characters don’t have their content indexed. Those files are correctly assigned to have their contents indexed by the macOS RichText mdimporter, according to their UTI. However, at the start of content indexing the text is checked for its ‘magic’ content. Those files that aren’t indexed because their opening bytes are recognised as being those of other types, and indexing is abandoned because of an error in the mdimporter. Examples of opening UTF-8 characters that can trigger this include the uncommon LG and HPA, and more common Draw.

Further details.

This is the strangest bug among these, as the Rich Text mdimporter is supposed to index content according to the UTI of the file being indexed, which is being recognised correctly. There should be no need to perform another less reliable method of file type recognition using the ‘magic’ rules that is then causing content indexing to fail. That appears to have been introduced over seven years ago, but never tested adequately against a suitable search corpus.

The same mdimporter had suffered another bug that failed to index the content of any Rich Text file that was also undetected for over six months in 2020-21. Without thorough testing of mdimporters, further bugs are likely to occur in release code and remain undetected for long periods.

Conclusions

• Of these five serious bugs in macOS 26.1, three are new to 26.1, one inherited from macOS 15, and one dates back seven years to macOS 10.14.
• At least two of the five appear to have been introduced when trying to fix earlier bugs.
• All five should have become obvious during testing, and none should have remained in any public release of macOS.
• Both of the bugs that were inherited from macOS 15 appear to reflect flawed design.
• Only one of the bugs, that in virtualisation, is noted in Apple’s developer release notes for 26.1, and that wasn’t carried forward to its release notes for users.

Acknowledgements

I’m very grateful to Rich Trouton, Michele, Paul, Jürgen, Drew, aldous and others who have provided invaluable information about these bugs.

Here’s a bonus riddle for this weekend: what’s so invisible you can never see it in the Finder, is in many of the folders in your Home folder, and can break your backups? The answer is a .DS_Store file, officially a Desktop Services Store. Although they might appear more ancient, they originated in Mac OS X when its Finder was being rewritten from scratch in 1999.

It had been intended that Desktop Services would eventually gain a public API, but somewhere along the line Apple decided to keep it private, and their format and function have never been officially documented. Its name starts with a dot/stop/period to make it invisible in the Finder, and since macOS Sierra it has been made invisible even when the Finder reveals other invisible files. Currently the best way to see it is in Terminal, where the -a option to ls should include .DS_Store files.

They can be confused with another annoying but more useful hidden file: shadow files whose names start with ._ that are used to carry extended attribute data as part of the AppleDouble file format used on some FAT file systems. They too are invisible in the Finder even when hidden files are supposed to be displayed, but are associated with individual files rather than folders.

Function

The Finder will normally create a .DS_Store file in a folder that you have write access to, when some change is made to it in the Finder, such as creating or copying a file into that folder.

.DS_Store files contain a folder’s custom attributes, data like icon positions, and in more recent versions of macOS custom settings for the display of file metadata.

Among the most important of their contents for some users are Finder or Spotlight Comments, which are normally displayed in the Comments section of the Get Info dialog for a file. Those comments may also be duplicated in the com.apple.metadata:kMDItemFinderComment extended attribute (xattr) of that file, but that’s a secondary copy that can fall out of sync with what’s stored in the .DS_Store file, and the Finder ignores the xattr anyway. The reliance of Finder Comments on invisible .DS_Store files can lead to their unreliability compared with other forms of metadata.

Problems

You’re more likely to come across .DS_Store files when they make a nuisance of themselves by tripping something up. Send a folder from your Mac to a Windows or Linux system, for example, and it’s likely to confuse the recipient with that mysterious extra file that you can’t see at all. Send a folder to another Mac by AirDrop, and any .DS_Store file inside it will also accompany its visible contents. That in turn can cause problems with some backup utilities if it results in an older .DS_Store file being found in a folder that has already been backed up with a newer one.

Recent versions of macOS should no longer write .DS_Store files to computers connected to them over a network. If you want to stop them from being exposed in network volumes of older systems, use the command
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true
to disable that. One place .DS_Store files can prove particularly troublesome is in Git repositories. Mikey @0xmachos has provided a simple solution for eradicating them.

At one stage Apple even recommended that they should be explicitly excluded from servers used for network backups or other storage. They can trip up revision control systems, baffle those who open archives created on a Mac, stop folder copying, and confound folder comparison. The simple solution to these, as with so many other problems with .DS_Stores, is to open the folder containing that hidden file, move some of its contents about to force it to be refreshed, and move on.

In the past, .DS_Store files have been suspected of leaking data, and were involved in at least one security vulnerability. Thankfully they now seem as puzzling and opaque to the developers of malware as they are to other users, but I’m sure that one day, someone else will try to do bad things with them again.

Removal

You can recursively delete .DS_Store files from a hierarchy using the command
find . -name .DS_Store -delete
and Ross Tulloch’s BlueHarvest can automatically remove them.

Here are two reports on bugs affecting macOS Tahoe 26.1 that might make you wait before updating.

macOS VMs can’t access iCloud

If you update a macOS virtual machine to 26.1, or create a new VM in 26.1, it loses its Serial number, which is apparently set as 0. Although most things you might do with a VM aren’t affected by that, it will prevent that VM from being able to access iCloud (if that has been enabled for the VM) and related features.

There’s no workaround for this, as serial numbers are created when the VM is first made, and the user can’t add or change them after that. If your VM needs access to iCloud, keep it running 26.0.1 instead.

I’m very grateful to Rich Trouton of Der Flounder for this information, which is also given in Apple’s developer release notes.

Finder Services

In some Finder views, such as Column View, selecting an item at the left displays the item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

I’m very grateful to Michele for letting me know of this.

If you know of any serious bug that is new to 26.1, please let me know and I’ll add it to this list after confirmation.

Last week I drew attention to problems interpreting the timestamps of files in macOS, generating lively discussion with Chris and Richard. Although the gist of that article stands, it was clear that there remained several issues, and this sequel tries to address those better, with the aid of a new app, Dropera 2. The TL;DR for this article is that timestamps are even more complicated than I previously described.

The first task was to develop a tool for reading and recording these timestamps reproducibly. Although the four key timestamps are exposed in Precize, opening a file in that app is likely to change at least one of them. For a substitute I turned to an earlier SwiftUI demo, Dropera, with its drag-and-drop support to handle file URLs without opening, reading or otherwise changing the file.

Timestamps

This new version of Dropera had then to read the right timestamps and convert them into accessible dates and times. For some timestamps, we’re spoiled for choice: time of creation of a file, shown in the Finder as Date Created, is saved in an APFS file’s attributes as create_time, exposed in the stat command as st_birthtime, and accessible within an app’s code as the NSFileCreationDate file attribute or creationDate URL resource. To establish which timestamp is which, I have compiled a table giving the sources I have been able to discover.

For Dropera, following careful comparison with the values delivered in stat, I selected:

• Creation from NSFileCreationDate
• Modification from NSFileModificationDate
• Attribute modification from attributeModificationDate
• Access from contentAccessDate.

The last two aren’t available in the Finder or elsewhere in the GUI, while the Finder does provide Date Last Opened, Date Added and Content Created:

• Date Last Opened isn’t related to Access Time, but is recorded in the com.apple.useddate extended attribute. Unfortunately, adding and manipulating that may change the Attribute Modification timestamp, so has to be avoided. As Apple doesn’t appear to document the xattr or its interpretation, I have avoided looking at it any further here.
• Date Added is the timestamp when a file was added to its current directory. As that isn’t strictly speaking a file attribute, I will ignore it here.
• Embedded records of Content Created require file data to be read, so accessing them is likely to update at least one of the key timestamps.

Each of those three is available from the metadata indexed by Spotlight, but that’s an indirect and unreliable way to access them.

Using Dropera

To use Dropera to read the four key timestamps just drop the file onto its window, and the app will then display the filename, its path, and the four timestamps in the order of Creation, Modification, Attribute modification and Access times.

Adjust the window width to make these most convenient to read. The layout shown above is compact and automatically splits each timestamp into date and time components. In other uses, you might prefer to widen the window so each entry takes a single line.

To refresh the values shown for the current files, click on the Refresh tool. Although the window continues to display just the single set of entries, the previous timestamps are saved in memory, and the whole history since the last drag-and-drop onto that window can be exported to a text file using the Save as text tool. You can also select the line of results, copy and paste that into another app if you prefer.

Drop multiple files onto Dropera’s window and all their timestamps will be shown. You can then select continuously (Shift-click) or discontinuously (Command-click) to copy those values, and Refresh them.

Demonstration

Open TextEdit, create a new file and set its type to plain text. Add a few words and save it somewhere convenient. Then open Dropera, and drop that file onto its window to inspect its timestamps. They’re likely to show Creation and Modification times the same, Attribute modification slightly later, and Access another second or so afterwards.

Next make a small change to that document and save it. Click Dropera’s Refresh tool and only the Creation time remains unchanged. Close that document in TextEdit, and Refresh the times again to confirm that none have changed. Now select the file in the Finder so its QuickLook thumbnail is previewed. When you Refresh its times, you should see its Access time has been updated. Now double-click the file to open it in TextEdit, and check times again while the file is still open. Attribute modification and Access times are altered, but remain the same after you have closed the document. Export those records as a text file, and you should see:

• Creation time remains unchanged throughout.
• Modification time changes once, when the second version was saved.
• Attribute modification time changes twice, when the modified file was saved, and when the file was reopened.
• Access time changes three times, the additional occasion being when you viewed the document’s thumbnail in the Finder.

Dropera 2, which requires macOS 14.6 or later, is available from here: dropera20

Enjoy!

One of the most fundamental changes brought by the Mac was the ability to open and edit files without having to explicitly specify which app to use. Instead of typing in a command telling an app to open a file, we can simply double-click the file and the Mac already knows which app to use. This relies on every file having a type, and the association between file types and apps. This article explains how that is now accomplished in macOS.

History

Classic Mac OS relies on two four-character codes assigned to every file designating their creator and type. An app has a type of APPL, and a text file a type of TEXT. A text file created by the TeachText app might have a creator code of TTXT and a type code of TEXT. Double-click on that file and the Finder looks for the app (with a type code of APPL) with the creator code of TTXT, and asks that to open the file. Associations between app creator codes and file types are also built into the Finder’s Desktop databases to relate icons with file types, forming the heart of the Desktop metaphor.

Although Mac OS X retained type and creator codes, early versions relied on filename extensions to determine the type of files, a feature of older operating systems and NeXTSTEP. Apple therefore invented a new system for identification and classification of file types and more using Uniform Type Identifiers, introduced in Mac OS X 10.4 Tiger. They have since been incorporated into a generalised UTType structure in macOS 11 Big Sur.

UTI

The standard system in macOS is based on a Uniform Type Identifier, or UTI, like public.plain-text for a plain text file, and public.jpeg for a JPEG image.

UTIs use a structured hierarchical taxonomy forming a vast interconnected tree. For example, when I write a file of Swift source code, the .swift file has the type public.swift-source, a specialised type of public.source-code, which is public.plain-text, which is public.text, and in turn both public.data and public.content. When I open that file, LaunchServices first looks for an editor for public.swift-source files, but can ascend the UTI tree as necessary and use an app designed to open text files of public.text more generally. Some of the more frequently encountered UTIs are shown in the diagram below, which you’ll probably need to expand to full screen to read clearly.

Determining the UTI

It’s often claimed that macOS depends on filename extensions to determine different types of file, but that’s not correct: it’s more capable, and uses MIME types when downloading from the Internet, and ultimately relies on UTIs.

This is easily demonstrated in Terminal. Type the following command
touch notypefile
to create a new file in the current directory without any extension or other clue as to what it is. Then look in the Finder’s Get Info dialog, and you should see that macOS has already assigned it a default type associating it with a default editor. Inspect that file using my free utility Precize, and you’ll see that it has a UTI (listed in the Type entry) of public.data.

Now give it an extension unknown to macOS, such as .xyz, and inspect it again with Precize: its type has changed to something more cryptic like dyn.ah62d4rv4ge81u8p4. That’s a dynamic UTI, created on the fly by macOS to distinguish it as having a unique type, described in Get Info simply as a Document, but still with its default associated editor.

Every item in your Mac’s file system has a UTI to tell LaunchServices what to do when you try to open it, for instance by double-clicking its icon. You may find an exception to this, from a longstanding bug dating back to OS X 10.5 in 2007: some files may not return a UTI, but a NULL instead. This seems to be confined to sockets, which might appear to be files but aren’t really.

Discovering the UTI

Unfortunately, although discovering UTIs is key to dealing with documents which are treated as having the wrong type, there’s no easy way to find a file’s UTI in macOS. Thankfully you don’t need long reference lists to find out key information such as what a filename extension or MIME type represents in terms of a UTI: it’s all contained within macOS, if you know how to look using one of the tools listed below.

My own utility for working with UTIs is UTIutility. Its main window lets you enter an extension like xls, and tells you all macOS knows about that and its corresponding UTI. Alternatively, you can open its Crawler window and get it to list all the UTIs it comes across in the selected folder. That can take a long time to work through large folders, or those loaded with UTIs like /Applications, but its results are revealing.

The correct answer to the question of what determines a file’s type is therefore a whole list:

• UTI, e.g. com.adobe.pdf,
• filename extension, e.g pdf,
• OSType, e.g. PDF,
• MIME type, e.g. application/pdf, or
• Pasteboard type, e.g. Apple PDF pasteboard type.

While you can change a file’s type directly by giving it a different UTI, it’s far simpler to do that indirectly by changing its extension to one correct for the type, such as txt or text for a text file. MIME types are mainly used for Internet file transfers, and Pasteboards are used when copying chunks of data using the Clipboard, which relies on the same basic system.

Other uses

In addition to LaunchServices making the association between the type of file you want to open and the app to use for that, UTIs are used extensively in macOS to determine how to handle different types of file. Among the more important are QuickLook, when deciding which generator to use to build a file’s thumbnail and preview, and Spotlight, when deciding which importer to use to index the contents of a file. Indeed, UTIs are so central to Spotlight that the command used in Terminal to inspect a file UTI is mdls, part of Spotlight.

Tools

Thomas Tempelmann’s free Launch Services features an excellent UTI browser.
Precize and UTIutility are free from their Product Page.

Apple documentation

UTI overview (archived)
Framework doc (current)
System-declared UTIs (current)
UTType (current).

macOS 26 Tahoe has many smaller enhancements to make life easier. Among them is a novel way of customising folder icons, as explained here.

Traditional custom folder icons

One of the most ancient features in macOS is adding a different icon to a file or folder, by pasting it into the top left of the Get Info dialog for that item. I have detailed how to do that, and how it works, in this article. While that still works, it has some significant limitations and is fiddly.

Another disappointing behaviour in previous macOS is the effect of adding coloured Finder tags to folders, which don’t change the colour of the folder as displayed.

Tahoe custom folders

macOS 26 changes the behaviour of folder icons in three ways:

• Default folder colour is now set in Appearance settings. In most cases, that will be left to use the Theme colour.
• Applying a coloured Finder tag to a folder now changes the colour of that folder, as well as displaying a coloured dot.
• Folders can be customised additionally using the Customise Folder… command in the Finder’s File or contextual menu.

The last of those merits further attention, and an explanation of how it works.

Customising folders

Rather than adding an arbitrary icon to a folder, Tahoe’s custom folders consist of a traditional folder icon with a symbol or emoji superimposed. These are selected from a wide range of vector graphic symbols drawn from Apple’s huge SF Symbols collection, or the standard range of Unicode emoji.

Symbols appear embossed with little difference in tone, so aren’t easy to distinguish unless the folder icon is quite large. This isn’t suitable for use in the Finder’s Column or List views.

The familiar range of emoji is usually clearer and readily distinguishable in most sizes.

Adding a coloured Finder tag to a customised folder makes it even more distinctive, and increases colour contrast with the emoji.

Not only does this look good, but it solves the problems associated with old-style custom folder icons. Copy that folder anywhere within your Mac, and its new look goes with it. Move it into iCloud Drive, and it goes there too. Although Macs and devices running older versions don’t show the custom folder in its full glory, those running OS 26 do. Yes, open Files on your iPhone and you’ll see the custom icon there too.

The only shortcoming that I can find is that, while you can search for specific Finder tags in Spotlight, you can’t search for the symbol or emoji displayed on the folder icon. There is a search attribute Custom Icon, but these folders aren’t considered to have that attribute.

How it works

Tahoe’s custom folders rely on a combination of two extended attributes (xattrs) attached to the folder:

• com.apple.FinderInfo, 32 bytes that is also used in other Finder settings;
• com.apple.icon.folder, new to Tahoe and containing details of the symbol or emoji to be displayed.

Both have to be attached to the folder for it to be displayed correctly.

com.apple.icon.folder is of particular interest, as it has an S flag, and is itself usually displayed as com.apple.icon.folder#S. The S tells macOS that xattr should be preserved during syncing with services such as iCloud Drive. A full list of xattr flags is given in the Appendix. This xattr contains a Unicode string such as
{"emoji":"🔍"}
for an emoji, or
{"sym":"person.crop.circle")
for one of the vector graphics in SF Symbols. The first is self-explanatory, while the second uses the name of that symbol in the SF Symbols library. This currently only supports a subset of the whole library, and my attempts to get it to use others from SF Symbols have so far failed.

Conclusion

macOS has succeeded because of its attention to detail. Tahoe’s new custom folders are an excellent example. Enjoy them!

Postscript

For those who want to disable Tahoe’s default of colouring tagged folders according to one of the tag colours, I’ve now discovered that you can disable that in the control Tint folder based on tags at the foot of the Tags view in Finder’s Settings.

Appendix: Xattr flags

Flags can be upper or lower case letters C, N, P, S or B, and invariably follow the # separator, which is presumably otherwise forbidden from use in a xattr’s name. Upper case sets or enables that property, while lower case clears or disables that property. There are currently five properties:

• C: XATTR_FLAG_CONTENT_DEPENDENT, which ties the flag and the file contents, so the xattr is rewritten when the file data changes. This is normally used for checksums and hashes, text encoding, and position information. The xattr is preserved for copy and share, but not in a safe save.
• P: XATTR_FLAG_NO_EXPORT, which doesn’t export or share the xattr, but normally preserves it during copying.
• N: XATTR_FLAG_NEVER_PRESERVE, which ensures the xattr is never copied, even when copying the file.
• S: XATTR_FLAG_SYNCABLE, which ensures the xattr is preserved during syncing with services such as iCloud Drive. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this will override that.
• B: XATTR_FLAG_ONLY_BACKUP, which keeps the xattr only in backups, including Time Machine (added recently).

These operate within another general restriction of xattrs: their name cannot exceed a maximum of 127 UTF-8 characters.