Where Do Changes Made by an onEvent Action Go?

Depending on the item -- whether it's a batch file, executable or just a text file -- that's being triggered by an OnEvent action, you can get a different owner of that item. There's really only three possibilities: Base, Layer, Different layer.

Read on to learn more.

Being launched by an OnEvent action doesn't mean the layer that has the OnEvent automatically take ownership. For the most part, the rules for who owns an action are pretty simple: If the item being triggered is in the Base or in the layer's Meta Directory, the base will get the changes. All other changes will go to the layer that has the triggered item. So if, for example, we're using a program that just creates a text file (for a log, lets say) and it's in the base or a layer's Meta Directory, that log file will get saved to the base.

If the .exe is in the layer that has the OnEvent action, the log file will get saved in that layer. If that .exe is in a different layer, it will get created in that layer. The reason for this is simple; it's how SVS works. The .exe is in a different layer so that layer owns our logger and all changes it makes go to that layer regardless of what called it.

There are exceptions to this rule, most notably OnPreCapture with a Global Capture. This will always capture to the layer going into capture mode. It doesn't matter if it's a Global OnEvent, or if our .exe is in the Meta Directory or in a different layer -- it will get captured into the layer starting the Global Capture.

The following chart shows where changes go based off the .exe being in the base, layer, or in the Meta Directory. I also show Global OnEvent actions with the .exe in the base.

A note on Global Events

There are some onEvent actions that will only work when set as a Global exclude, that's because the layer doesn't exist at the time when a call can be made (onPreImport, both capture events and onPostDelete) so there's no way for you to even create layer based onEvent actions for them that SVS will be able to use.

A note on items in layers

You'll notice in the chart below that when an item being triggered by an onEvent is in a layer, that it doesn't work a lot of times. This is assuming the item being called is in the same layer that does the calling. The reason for all the non-working events is if the layer isn't active, that item doesn't exist to the system so even though the onEvent call is being triggered, Windows cannot find what you're calling. Yes, you could point to something in the FSLRDR directory but that would be the same as pointing to something in the base. Since the layer isn't active those changes won't get tracked by SVS.

Lastly is the Fail assigned to OnPreReset when the item is in a layer. I'm pretty sure that's a bug. What's happening is if the layer is active it gets deactivated before OnPreReset is triggered so the item being called in the layer doesn't exist. Also note that with the PostRest onEvent actions, that if the OnEvent is in the read/write sublayer or if the item being called is in that sublayer then it won't work because it will be deleted during the Rest.