Prime Day can't-miss deals Cheapskate's favorite Prime Day deals Target's rival sale Walmart's competing sale Best Buy's me-too sale IRS child tax credit portal

Residual '.SM.gul' files in OS X may confuse your Mac

If interrupted, Apple's Migration Assistant may leave residual files behind that can cause odd and unwanted system behavior.

When migrating or restoring your Mac using Apple's Migration Assistant utility, if you have cancelled the migration operation or experienced an error such as a power outage or crash, then you may find some odd behavior. Changes made to some system resources might not be recognized.

For instance, if you have third-party utilities installed on your system that use launch agents or daemons to keep them running, if you decide to disable these agents by removing them from your system, you might find the programs continue to launch.

Recently I ran into such a situation. When migrating to a new Mac system I found changes I made to launch agent files were not taking effect. One common security tool that I often recommend is the reverse firewall Little Snitch from Objective Development. This tool runs in part by using a launch agent to load files at startup and keep them alive as you use your system. However, something went awry with the Little Snitch installation that caused it to not start correctly, which resulted in repeated "Throttling Respawn" messages in the system console.

Throttling Respawn messages in the Console
Throttling Respawn messages suggest the program is not launching properly, though these should disappear if the launch agent associated with them is removed. Screenshot by Topher Kessler/CNET

To clear the problem temporarily I decided to remove the Little Snitch launch agent file from its place in the /Library/Launch Agents/ folder. After restarting the system I found the Throttling Respawn messages persisting in the system console. I was concerned, since removing the launch agent means the system should not have loaded the instructions to launch Little Snitch at boot, but it was happening.

Since the launch process only loads daemon and agent files from the Launch Agents and Launch Daemons directories in the user library, global library, and system library, I checked those locations to see if a duplicate of the launch daemon was present. Not finding any, the only option I could think of was to use the Terminal's "ls -la" command on the various launch agent and daemon folders to see if any contained a hidden copy of the problematic launch agent file.

Doing so showed practically all of the launch agent and daemon scripts on the system existed in duplicate form as hidden files with the prefix ".SM.gul," which because of the preceding period were hidden from view in the Finder. However, since the rest of the file names ended in .plist and were otherwise structured as launch agents and daemons, the system recognized them as such and continued to load them.

The .SM.gul files had littered the system, and resulted in not only problems with the launch agent files, but also with other files. In the Displays system preferences, the system listed a number of color profiles all listed as "Display" in italics, instead of the default and manually calibrated displays, and upon checking the color profiles in the system folder found them to also be duplicated in a similar manner. In addition, numerous fonts had been duplicated.

Since this happened after migrating the system, I suspected an error in the migration process was involved. Apple's migration is performed in part by the System Migration framework, so to see if the filename prefix was associated with this framework I ran the following command in the Terminal, followed by opening the file "strings.txt" that it creates in the home folder:

sudo strings - /System/Library/PrivateFrameworks/SystemMigration.framework/SystemMigration > ~/strings.txt

System Migration framework string list
The prefix string is found several times in the System Migration framework. Screenshot by Topher Kessler/CNET

This command searches for text string values within the compiled binary of the framework and dumps any that are found to the "strings.txt" file. When opening the file you can see several references to the .SM.gul prefix listed, indicating the framework is likely associated with the creation of these files.

Apparently when migrating files, the system will append this prefix to a number of them during the transfer, and then change the name at a later point when the migration completes. However, if as in my case an error or interruption happens then the prefixed files might be left behind, resulting in duplicates when you either reinstall OS X or if you decided to migrate a second time after not succeeding the first time.

If this problem happens on your system and you are finding .SM.gul files littered throughout the filesystem, then you should be able to remove them without any harm to the system, and in fact in doing so clean up a number of problems such as the ones outlined above. To do this, the best method is to use the system's "locate" database (similar to Spotlight), which is disabled by default but can be enabled by running the following command in the Terminal:

sudo launchctl load -w /System/Library/LaunchDaemons/

Then open Activity Monitor and locate the process called "find," which should be running and using a small amount of your CPU to index the files on your hard drive. Wait until this process quits (up to a few hours), and then run the following command in the Terminal to see how extensive the littering of .SM.gul files is on your system:

Hidden .SM.gul files in the Finder
Using the file list created in your home directory, after you have shown hidden files in the Finder you can locate the hidden .SM.gul files and remove them manually. Screenshot by Topher Kessler/CNET

sudo locate .SM.gul.*

The resulting output from this command may be a large list, so you can pipe it to a file in your home folder by repeating the command in the following manner:

sudo locate .SM.gul.* > ~/files.txt

In this command, similar to the "strings" command above, you will now have a file called "files.txt" in your home directory, which will contain the output of the command.

At this point you can see all the duplicate files on the system, and so use this list as a reference for locating and removing them. While you can use the Terminal to remove these files, if you make mistakes in the Terminal with its various commands to remove files, you can result in doing great harm to the OS and your data. So instead use the Finder by first enabling hidden files with the following Terminal command, followed by logging out and logging back in:

defaults write AppleShowAllFiles 1

When completed, you should now see hidden files listed alongside your regularly visible files and folders. Now use your .SM.gul list to find where the duplicate files are located, and delete them manually using the Finder. To aid this process you can run the "sudo locate .SM.gul.* > ~/files.txt" command numerous times as you delete these duplicates to update the file, so it only shows which of the duplicates are left.

Once completed, your system should be void of these duplicate files, and you can then turn off the hidden files in the Finder by running the following command:

defaults write AppleShowAllFiles 0

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.