Event Scripting Details

File system events

The file system events can express creation of a directory (mkdir), modification of a file (write), deletion of a file (delete) or renaming of a file (rename). When replayed, these events cause the corresponding affect on the file system.

Note that creation of a file is implicitly done when the file is first written to.

mkdir

  {
    "type": "mkdir",
    "name": "{0}/foo"
  }

write

  {
    "type": "write",
    "name": "{0}/foo/x",
    "content": "Hello world"
  }

delete

  {
    "type": "delete",
    "name": "{0}/foo/x",
  }

rename

  {
    "type": "rename",
    "from": "{0}/foo/x",
    "from": "{0}/foo/y",
  }

FileWatcher events

The file watcher events all look like this

  {
    "type": "watch-event",
    "event": {
      "root": "{0}",
      "create_path": "foo/x", "delete_path": null, "modify_path": null
    }
  }

The trick is that the three sub-fields in the event field can have one non-null value which defines the path of interest and by implication from which field is non-null, you can tell what the operation is.

The rationale for this representation is that it allows events to be coalesced and that makes it easier to interpret a delete+create as a single rename operation.

This is a pretty low-level rationale, but these events are normally entirely internal to the monitor program itself and are only exposed so that we can build tests that hit strange racy corners.

Monitor stream events

create modify delete rename_from rename_to

Template expansion

All of the strings in events are subject to expansion before being interpreted. This is primarily so that we don't have to put full path names into the events. Right now the only expansion is that the string {0} is expanded into a test directory that is created at the beginning of a test. This is normally used as the root directory for all events.

Access from Java