File System Permissions and File System Events

The most obvious security concern related to file system events is one of privacy. If Bob can see a list of events from changes to Alice’s home directory, Bob might see things that Alice does not want him to see. For example, Alice might have a directory name that coincides with the code name of an unreleased Apple product.

To prevent this potential security leak, users do not receive any events unless the user can reach the modified directory through standard file system permissions.

Deleted Files and File System Events

When files or directories are deleted, these events look just like any other file system event. This means that directory names will linger on your computer even after a file is deleted.

It is not possible to remove individual records programmatically. The only way to remove prior entries in the database is to purge all entries prior to a particular entry ID. You can do this by calling FSEventsPurgeEventsForDeviceUpToEventId in your application.

While the gzipped data is stored in a series of files in the .fseventsd directory at the root level of each volume (accessible only by the root user), you should never work with the data directly, as the format of these files may change at any time.

Preventing File System Event Storage

In some cases, the contents of a volume are sufficiently secret that it is not appropriate to log them. To disable logging on a per-volume basis (for creating a backup volume, for example), you must do the following:

• Create a .fseventsd directory at the top level of the volume.

• Create an empty no_log file in that directory.

So if your volume is mounted at /Volumes/MyDisk, you would create an empty file called /Volumes/MyDisk/.fseventsd/no_log.