On Wed, Oct 5, 2011 at 1:24 AM, Dave Page
<dpage@pgadmin.org> wrote:
On Wednesday, October 5, 2011, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Dave Page, 04.10.2011 21:46:
>>
>> We updated our build system to use BitRock 7 today (for unrelated
>> reasons) which has new features for ACL management. We're going to
>> investigate replacing cacls/icacls with those features tomorrow and
>> will create some test builds ASAP.
>
> If you can provide the test builds publicly, I will be happy to test them and see if that behaves differently on my system.
Thanks, we will.
As someone who recently spent a couple of days fighting with icacls, I thought I might offer some insight here. What I discovered through trial and error and much googling is that icacls has some non-intuitive behaviors which are not at all obvious from just reading the documentation. For example, it behaved entirely differently if you run it against a directory instead of a file (which may contain wildcards). The command icacls.exe C:\mydir\ <options> (when we targeted a directory) applied <options> to every file in C:\mydir\ and all subdirectories. icacls.exe C:\mydir\* <options> (when we targeted a file) applied <options> to all files in C:\, but did not apply options to files in subdirectories unless the /t switch was provided. This behavior is not directly mentioned in the documentation, but can be inferred from the first 2 examples, if you look at them carefully. Also, in the syntax description, the /t switch is shown for the icacls.exe <FileName> syntax, but not for the icacls.exe <Directory> syntax. I never would have noticed these if I weren't looking specifically for an explanation of the observed behavior. As far as how to use icacls to set permisions on a directory (as opposed to the files in a directory) without recursing to all subdirectories, I never did succeed in finding that out.
