Yesterday’s exploration of the strange problem of vanishing Recent Items raised some questions which this article will try to answer.

Some time ago, the Recent Items feature was brought under the wing of what Apple calls Launch Services, according to its limited documentation. Launch Services handles an eclectic mixture of tasks, some of which used to be the Finder’s responsibility, including:

• launching apps from other apps;
• opening documents or URLs in other apps;
• identifying the default app with which to open a document or URL;
• maintaining lists of document and URL types which an app can open;
• providing ancillary information about files and URLs, such as an associated icon;
• maintaining and handling Recent Items for the Finder and apps.

These can perhaps be summarised as managing the relationship between apps and their document and URL types.

Generally speaking, problems with Launch Services are infrequent, the most common being failures in document and app association, in which your Mac associates the wrong app with a particular document (or URL) type. These are usually fixed by remaking that association, for example in the Finder’s Get Info… dialog. Interestingly when I had my problem with Recent Items, I had noticed an issue with misassociation, in which the Finder decided it wanted to open all text documents using Script Debugger.

Although Apple’s guide explains how Launch Services makes the associations between apps and document types, and is useful reading for that, it glosses over the management of Recent Items. So here is a bit more detail.

Stored data

Recent Items depends entirely on a hierarchy of SharedFileLists (extension .sfl) kept in ~/Library/com.apple.sharedfilelist; there are none in the top-level /Library folder. At the top level of com.apple.sharedfilelist are eight files which cover general and Finder information, listing favourite and recent apps, documents, hosts, and servers.

Within that, another folder named com.apple.LSSharedFileList.ApplicationRecentDocuments contains hundreds of individual .sfl files for each app, listed according to their signature. For example, the Recent Items list for my Dystextia app is stored in co.eclecticlight.dystextia.sfl

These .sfl files are property lists which contain the saved keyed archive maintained by the sharedfilelistd service, and can be opened using a suitable text editor such as BBEdit. Embedded in each is a setting for the number of Recent Items, in the key-value pair
<string>com.apple.LSSharedFileList.MaxAmount</string>
<integer>10</integer>

However, that value is only updated when that file is next written to. When you change the number in the General pane, your change is reflected immediately in the .sfl files which are open for the Finder, and for other apps which are open at that time. sharedfilelistd (see below) works through those active .sfl files very quickly, but does not try to work through files in com.apple.LSSharedFileList.ApplicationRecentDocuments – those are updated only when their apps are opened.

I have been unable to find a preference file which contains the current number of Recent Items, and suspect that this is not recorded in one.

.sfl property lists contain a series of entries for each item in that app’s Recent Items, which includes its full path (URL). However, there doesn’t appear to be any record of the date or time of access to documents, which seem to be maintained as a simple queue: each time a document is opened, its details are added to the respective list. When the number of documents in each list exceeds the MaxAmount value, the oldest is removed (first in, first out, or FIFO).

Because .sfl files are only maintained when their app is open, they can contain extremely old document URLs.

The service

The background service which operates and maintains Recent Items is not lsd, but sharedfilelistd, of which two copies should be running, one for the current user, the other for root. Inevitably, this service is undocumented. It is controlled by a Launch Agent, in /System/Library/LaunchAgents/com.apple.coreservices.sharedfilelistd.plist, which is protected by SIP.

SharedFileList activity is easily spotted in Sierra’s log by filtering for the com.apple.sharedfilelist subsystem.

When the user opens a document in an app, this triggers the com.apple.sharedfilelist subsystem to add the document to the Finder’s lists and those of the app:
com.apple.sharedfilelist XPC Dystextia SharedFileList com.apple.LSSharedFileList.FavoriteItems
com.apple.sharedfilelist default sharedfilelistd sharedfilelistd <private>[3967] subscribed to list <private>
com.apple.sharedfilelist default sharedfilelistd sharedfilelistd <private>[3967] apply change <private> to list <private>
and so on

A similar sequence is seen when an app is launched, to add that to the Finder’s list of recent apps. This is initiated by
com.apple.CommCenter default CommCenter CommCenter #I CSIAppInfo.ApplicationActivationObserver: handleLSNotitifcation_sync: Application launched: <private>
which triggers the com.apple.sharedfilelist subsystem to add the app:
com.apple.sharedfilelist XPC Dock SharedFileList com.apple.LSSharedFileList.RecentApplications
com.apple.sharedfilelist default sharedfilelistd sharedfilelistd <private>[393] apply change <private> to list com.apple.LSSharedFileList.RecentApplications
and so on. Note that the typo of handleLSNotitifcation_sync is that recorded in the log. Searching for the correct form handleLSNotification_sync would therefore miss this entry.

Changing the number of Recent Items in the General pane is first reported in the log with the announcement:
com.apple.preference.general.remoteservice Appearance New number of recents: 20
but there is no entry indicating that this is recorded in a preference file.

This is followed by a long series of entries from the com.apple.sharedfilelist subsystem making the change in SharedFileLists of the Finder and open apps:
com.apple.sharedfilelist XPC com.apple.preference.general.remoteservice SharedFileList com.apple.LSSharedFileList.RecentApplications
com.apple.sharedfilelist default sharedfilelistd sharedfilelistd <private>[11033] apply change <private> to list com.apple.LSSharedFileList.RecentApplications
and so on.

Faults

These seem to be unusual and sporadic, although it’s hard to see how they occur. In my recent case, it appears that sharedfilelistd was still running, but was behaving incorrectly by adding new Recent Items to the Finder’s lists without maintaining their length, and failing to add them to other open apps, leaving their Recent Items lists empty.

It has been suggested that the simplest way to deal with problems with Recent Items is to
killall sharedfilelistd
which stops the service, letting launchd restart it. If you cannot log out and back in again, or restart, this is perhaps worth trying. However it may not result in the necessary housekeeping to .sfl files, and could allow the fault to recur rapidly. If you can, it is preferable to restart your Mac, which ensures that both copies of sharedfilelistd are run afresh, and they should then rectify any problems in .sfl files.

The Recent Items system in Sierra is quite complex, relying on sharedfilelistd maintaining many property lists containing records of recent items. Those records can contain information of historical document access, but its retention varies greatly, and those records are undated.