---
title: Controlling what happens to existing File Permissions when using the Activate API to Secure a Folder
slug: controlling-what-happens-to-existing-file-permissions-when-using-the-activate-api-to-secure-a-folder
createdAt: 2025-07-22T02:17:35.173Z
---

Out of the box, Activate uses the FileUtilities.SetDirectoryACLEx method to set permissions when applying security to NTFS Folders.

SetDirectoryACLEx(*path*, *accessControlList, action*)
See the Activate API documentation for the SetDirectoryACLEx overloads.

When SetDirectoryACLEx is run against a target folder that has existing permissions defined:

- the *accessControlList* parameter defines what happens to existing permissions defined directly on the target folder.
  e.g.
  - Prefixing with “-all;” overwrites any existing permissions and blocks inheritance
  - No prefix “adds” the specific permissions to the folder ACL and does not block inheritance
- The optional *action *parameter defines the changes that Activate will make to sub-folders that have permissions explicitly defined or inheritance disabled.
  The *action* parameter is a TreeSecInfoAction enumeration, the values for which (from TreeSecInfoAction in the Activate API) are:

| **Member name**       | **Value** | **Description**                                               | Action                                                                                                       |
| --------------------- | --------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Set**               | 1         | An enum constant representing the set option.                 | Adds new permissions to folders:<br />- Inheritance is not re-enabled.<br />- Existing ACEs are not removed. |
| **Reset**             | 2         | An enum constant representing the reset option.               | Overwrites existing permissions:<br />- Inheritance is re-enabled.<br />- Existing ACEs are removed.         |
| **ResetKeepExplicit** | 3         | An enum constant representing the reset keep explicit option. | A combination of the previous two:<br />- Inheritance is re-enabled.<br />- Existing ACEs are not removed.   |



## Example

When SetDirectoryACLEx is used against the folder structure



![](https://api.archbee.com/api/optimize/Lfto9rn2ELed8aLNOgwlJ/WYaI_mhZeJ4ldO4D2iAQQ_image.png)




| **Folder name**    | **Description**                                                            |
| ------------------ | -------------------------------------------------------------------------- |
| **Additional ACE** | Has a permission defined explicitly on the folder to grant a group access. |
| **No inheritance** | Has inheritance blocked and a new set of permissions defined.              |
| **Same as Test1**  | Only permissions inherited from Test1 apply.                               |

The results of the TreeSecInfoAction options are:

1. Additional ACE; The permission granting access to the group remains set.No inheritance; No change, i.e. inheritance is blocked and a new set of permissions defined.Same as Test1; No change, i.e. Only permissions inherited from Test1 apply.

2. Additional ACE; The permission granting access to the group is removed and only permissions inherited from Test1 apply.No inheritance; Inheritance is re-enabled and only permissions inherited from Test1 apply.Same as Test1; No change, i.e. Only permissions inherited from Test1 apply.

3. Additional ACE; The permission granting access to the group remains set.No inheritance; Inheritance is re-enabled and only permissions inherited from Test1 apply.Same as Test1; No change, i.e. Only permissions inherited from Test1 apply.