The name and the target represents a particular symlink sitting inside the folder schema somewhere - it is associated with a folder "node" which has a bunch of configuration attributes and options. When we do IO for these folder nodes we send through the configuration metadata into the IO subsystem and ultimately into the hook, allowing clients to pass configuration metadata from one of those folder yml files all the way into their hook code - the classic use case here is to manage file permissions.

When the IO operation is merely a file copy from the schema location to a target location (like a `workspace.mel` file for example), we have passed the metadata for the folder in which the workspace file resides along with additional IO info into the hook. The usefulness of this is arguable, however it is consistent with the rest of things.

this brings up a great point and I think we should pass in the yml def for the symlink rather than the hosting folder i the case of symlinks, allowing a user to do analogous modifications with custom config data for symlinks too. I'll make that change! Thanks for spotting!! :)

"action" is just "symlink" to distinguish it from "folder" "entity_folder", "copy_file" etc so that is implied by the type itself!

Hope my explanation makes sense!