Another confusing part of working with dispatch directories is how they are named. You can see the SID value (which is used as the directory name) in the search job inspector and it seems it has some meaningful information, but what is all that other stuff?
The dispatch directory name contains several elements, depending on the type of search. All include the time the search was run. In the case of a local ad-hoc search, that by itself is the entire dispatch directory name.
If it is from a saved search, the user requesting the search, the user context it is run as, and the app it came from are included. Searches from remote peers start with “remote” and real-time searches with “rt”.
The name of the search may or may not be used, depending on a few conditions. If it is short (less than 20 characters) and only contains alphanumeric characters, the directory name includes the search name. If it is 20 characters or longer, or contains non-alphanumeric characters, a hash is used instead. This is to ensure a directory named by the SID can actually be created on the filesystem.
One other thing for scheduled searches, there is an internal id added to the end to avoid name collisions.
Here are some dispatch directory examples:
ad-hoc search that uses a subsearch (two dispatch directories)
ad-hoc real time search
“feorlen1” – run by admin, in user context admin, saved in app search
“Errors in the last 24 hours” – run by somebody, in user context somebody, saved in app search
“Alert – syslog errors last hour” – run by the scheduler, with no user context, saved in app unix
“foo” – run by the scheduler, in user context admin, saved in app search
ad-hoc search from remote peer idx1
“foo2” search from remote peer idx1, run by its scheduler