On Wed, Oct 5, 2011 at 1:24 AM, Dave Page <dp...@pgadmin.org> wrote:
> > > On Wednesday, October 5, 2011, Thomas Kellerer <spam_ea...@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. > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > 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.
