As far as I can tell, normal permissions for a root directory (C:\) are:
BUILTIN\AdministratorsOI)(CI)F
NT AUTHORITY\SYSTEMOI)(CI)F
CREATOR OWNEROI)(CI)(IO)F
BUILTIN\USERSOI)(CI)R
BUILTIN\USERSCI)(special access)
FILE_APPEND_DATA
BUILTIN\USERSCI)(IO)(special access)
FILE_WRITE_DATA
Everyone:R

(I translated the words "special access". If I mistranslated, here's what
it really said:
$BFC<l$J%"%/%;%9(B)

The closest that I can produce is:
BUILTIN\AdministratorsOI)(CI)F
NT AUTHORITY\SYSTEMOI)(CI)F
BUILTIN\UsersOI)(CI)R

I don't even know how I got it to come as far as (OI) and (CI). When I
tried to specify these qualifiers in a CACLS command, it told me the
meanings but it refused to obey.

How can I give USERS the special access right of FILE_APPEND_DATA and make
it (CI) only?

How can I give USERS the special access right of FILE_WRITE_DATA and make it
(CI)(IO) only? And what does the combination of (CI) and (IO) mean, since
(CI) means it includes the current directory and subfolders but (IO) means
it excludes the current directory?

The way I got to this stupid position was that first I tried to use Windows
Explorer's security tab to give one additional user a privilege to write in
the C:\ directory, and Windows Explorer hanged. So I tried to use the CACLS
command, which naturally deleted all privileges for users other than the one
that I gave that new write privilege to. I'm not sure how I was able to
partially restore the privileges to the three shown above, since I
supposedly no longer had privilege to set privileges. Yeah from that
experience I learned what the /E flag means.

I've read http://support.microsoft.com/?kbid=318754
which says there is no way to specify FILE_APPEND_DATA or FILE_WRITE_DATA
because they're subsets of basic access rights, but I'm not a good enough
guesser to guess which basic access rights these are. Which basic access
rights are (CI) only, and which basic access rights are (CI)(IO)(whatever it
means to both include and exclude the current directory).

I've read the output of XCACLS /?

> filename Displays ACLs.

Yeah so when I want to set instead of display, I omit filename and it
complains.

> Spec can be the same as perm and will only be
> applied to a directory. In this case, Perm
> will be used for file inheritence in this
> directory. If not omitted: Spec=Perm. Special values
> for Spec only:
> T Not Specified (for file inherit,
> only for dirs valid)
> At least one access right has to follow!
> Entries between ';' and T will be ignored!

If spec is the same as perm then it will only be applied to a directory,
which in this case is C:\. In this case perm will be used for file
inheritence. Now I'm lost again, is it only applied to the directory or is
it only used for file inheritence? Or maybe really used for something else
entirely?

If not omitted: Spec=Perm. Really useful, that. If it is omitted then it
can be used for ... No I give up. If not omitted then it's used for ... I
got it, it applies to both the directory and for file inheritance because
it's the same as perm.

Well, omitting or not omitting, the closest I've come to making it correct
is:

C:\>cacls c:\ /g administrators:f system:f users:r
$B$h$m$7$$$G$9$+(B (Y/N)?y
$B=hM}%G%#%l%/%H%j(B: c:\

C:\>xcacls c:\
c:\ BUILTIN\AdministratorsOI)(CI)F
NT AUTHORITY\SYSTEMOI)(CI)F
BUILTIN\UsersOI)(CI)R

When I tried xcacls with the same parameters, it weirded the results worse.

Can anyone say how to restore it to this:
BUILTIN\AdministratorsOI)(CI)F
NT AUTHORITY\SYSTEMOI)(CI)F
CREATOR OWNEROI)(CI)(IO)F
BUILTIN\USERSOI)(CI)R
BUILTIN\USERSCI)(special access)
FILE_APPEND_DATA
BUILTIN\USERSCI)(IO)(special access)
FILE_WRITE_DATA

If you have not tried it yet take a look at using xcacls.vbs which is more
powerful and easier to use than the others. There are also free third party
tools like fileacl that you may also want to look into. --- Steve

http://support.microsoft.com/?id=825751 --- Xcacls.vbs

"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:Oh3tdIoCGHA.516@TK2MSFTNGP15.phx.gbl...
> As far as I can tell, normal permissions for a root directory (C:\) are:
> BUILTIN\AdministratorsOI)(CI)F
> NT AUTHORITY\SYSTEMOI)(CI)F
> CREATOR OWNEROI)(CI)(IO)F
> BUILTIN\USERSOI)(CI)R
> BUILTIN\USERSCI)(special access)
> FILE_APPEND_DATA
> BUILTIN\USERSCI)(IO)(special access)
> FILE_WRITE_DATA
> Everyone:R
>
> (I translated the words "special access". If I mistranslated, here's what
> it really said:
> $BFC<l$J%"%/%;%9(B)
>
> The closest that I can produce is:
> BUILTIN\AdministratorsOI)(CI)F
> NT AUTHORITY\SYSTEMOI)(CI)F
> BUILTIN\UsersOI)(CI)R
>
> I don't even know how I got it to come as far as (OI) and (CI). When I
> tried to specify these qualifiers in a CACLS command, it told me the
> meanings but it refused to obey.
>
> How can I give USERS the special access right of FILE_APPEND_DATA and make
> it (CI) only?
>
> How can I give USERS the special access right of FILE_WRITE_DATA and make
> it
> (CI)(IO) only? And what does the combination of (CI) and (IO) mean, since
> (CI) means it includes the current directory and subfolders but (IO) means
> it excludes the current directory?
>
> The way I got to this stupid position was that first I tried to use
> Windows
> Explorer's security tab to give one additional user a privilege to write
> in
> the C:\ directory, and Windows Explorer hanged. So I tried to use the
> CACLS
> command, which naturally deleted all privileges for users other than the
> one
> that I gave that new write privilege to. I'm not sure how I was able to
> partially restore the privileges to the three shown above, since I
> supposedly no longer had privilege to set privileges. Yeah from that
> experience I learned what the /E flag means.
>
> I've read http://support.microsoft.com/?kbid=318754
> which says there is no way to specify FILE_APPEND_DATA or FILE_WRITE_DATA
> because they're subsets of basic access rights, but I'm not a good enough
> guesser to guess which basic access rights these are. Which basic access
> rights are (CI) only, and which basic access rights are (CI)(IO)(whatever
> it
> means to both include and exclude the current directory).
>
> I've read the output of XCACLS /?
>
>> filename Displays ACLs.
>
> Yeah so when I want to set instead of display, I omit filename and it
> complains.
>
>> Spec can be the same as perm and will only be
>> applied to a directory. In this case, Perm
>> will be used for file inheritence in this
>> directory. If not omitted: Spec=Perm. Special values
>> for Spec only:
>> T Not Specified (for file inherit,
>> only for dirs valid)
>> At least one access right has to follow!
>> Entries between ';' and T will be ignored!
>
> If spec is the same as perm then it will only be applied to a directory,
> which in this case is C:\. In this case perm will be used for file
> inheritence. Now I'm lost again, is it only applied to the directory or
> is
> it only used for file inheritence? Or maybe really used for something
> else
> entirely?
>
> If not omitted: Spec=Perm. Really useful, that. If it is omitted then it
> can be used for ... No I give up. If not omitted then it's used for ...
> I
> got it, it applies to both the directory and for file inheritance because
> it's the same as perm.
>
> Well, omitting or not omitting, the closest I've come to making it correct
> is:
>
> C:\>cacls c:\ /g administrators:f system:f users:r
> $B$h$m$7$$$G$9$+(B (Y/N)?y
> $B=hM}%G%#%l%/%H%j(B: c:\
>
> C:\>xcacls c:\
> c:\ BUILTIN\AdministratorsOI)(CI)F
> NT AUTHORITY\SYSTEMOI)(CI)F
> BUILTIN\UsersOI)(CI)R
>
> When I tried xcacls with the same parameters, it weirded the results
> worse.
>
> Can anyone say how to restore it to this:
> BUILTIN\AdministratorsOI)(CI)F
> NT AUTHORITY\SYSTEMOI)(CI)F
> CREATOR OWNEROI)(CI)(IO)F
> BUILTIN\USERSOI)(CI)R
> BUILTIN\USERSCI)(special access)
> FILE_APPEND_DATA
> BUILTIN\USERSCI)(IO)(special access)
> FILE_WRITE_DATA
>

Thank you. But as far as I can tell, there's still no way to force
combinations of (OI), (CI), and (IO) to be set the way they were supposed to
be. The /I switch can be ENABLE or COPY or REMOVE but it can't be made
specific enough.

Anyone have XXCACLS.TXT.VBS? oops
Anyone have XXCACLS.VBS?

"Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
news:-sCdnYwTVc_0sS_eRVn-gg@comcast.com...
> If you have not tried it yet take a look at using xcacls.vbs which is more
> powerful and easier to use than the others. There are also free third
> party tools like fileacl that you may also want to look into. --- Steve
>
> http://support.microsoft.com/?id=825751 --- Xcacls.vbs
>
> "Norman Diamond" <ndiamond@community.nospam> wrote in message
> news:Oh3tdIoCGHA.516@TK2MSFTNGP15.phx.gbl...
>> As far as I can tell, normal permissions for a root directory (C:\) are:
>> BUILTIN\AdministratorsOI)(CI)F
>> NT AUTHORITY\SYSTEMOI)(CI)F
>> CREATOR OWNEROI)(CI)(IO)F
>> BUILTIN\USERSOI)(CI)R
>> BUILTIN\USERSCI)(special access)
>> FILE_APPEND_DATA
>> BUILTIN\USERSCI)(IO)(special access)
>> FILE_WRITE_DATA
>> Everyone:R
>>
>> (I translated the words "special access". If I mistranslated, here's
>> what
>> it really said:
>> $BFC<l$J%"%/%;%9(B)
>>
>> The closest that I can produce is:
>> BUILTIN\AdministratorsOI)(CI)F
>> NT AUTHORITY\SYSTEMOI)(CI)F
>> BUILTIN\UsersOI)(CI)R
>>
>> I don't even know how I got it to come as far as (OI) and (CI). When I
>> tried to specify these qualifiers in a CACLS command, it told me the
>> meanings but it refused to obey.
>>
>> How can I give USERS the special access right of FILE_APPEND_DATA and
>> make
>> it (CI) only?
>>
>> How can I give USERS the special access right of FILE_WRITE_DATA and make
>> it
>> (CI)(IO) only? And what does the combination of (CI) and (IO) mean,
>> since
>> (CI) means it includes the current directory and subfolders but (IO)
>> means
>> it excludes the current directory?
>>
>> The way I got to this stupid position was that first I tried to use
>> Windows
>> Explorer's security tab to give one additional user a privilege to write
>> in
>> the C:\ directory, and Windows Explorer hanged. So I tried to use the
>> CACLS
>> command, which naturally deleted all privileges for users other than the
>> one
>> that I gave that new write privilege to. I'm not sure how I was able to
>> partially restore the privileges to the three shown above, since I
>> supposedly no longer had privilege to set privileges. Yeah from that
>> experience I learned what the /E flag means.
>>
>> I've read http://support.microsoft.com/?kbid=318754
>> which says there is no way to specify FILE_APPEND_DATA or FILE_WRITE_DATA
>> because they're subsets of basic access rights, but I'm not a good enough
>> guesser to guess which basic access rights these are. Which basic access
>> rights are (CI) only, and which basic access rights are (CI)(IO)(whatever
>> it
>> means to both include and exclude the current directory).
>>
>> I've read the output of XCACLS /?
>>
>>> filename Displays ACLs.
>>
>> Yeah so when I want to set instead of display, I omit filename and it
>> complains.
>>
>>> Spec can be the same as perm and will only be
>>> applied to a directory. In this case, Perm
>>> will be used for file inheritence in this
>>> directory. If not omitted: Spec=Perm. Special values
>>> for Spec only:
>>> T Not Specified (for file inherit,
>>> only for dirs valid)
>>> At least one access right has to follow!
>>> Entries between ';' and T will be ignored!
>>
>> If spec is the same as perm then it will only be applied to a directory,
>> which in this case is C:\. In this case perm will be used for file
>> inheritence. Now I'm lost again, is it only applied to the directory or
>> is
>> it only used for file inheritence? Or maybe really used for something
>> else
>> entirely?
>>
>> If not omitted: Spec=Perm. Really useful, that. If it is omitted then
>> it
>> can be used for ... No I give up. If not omitted then it's used for ...
>> I
>> got it, it applies to both the directory and for file inheritance because
>> it's the same as perm.
>>
>> Well, omitting or not omitting, the closest I've come to making it
>> correct
>> is:
>>
>> C:\>cacls c:\ /g administrators:f system:f users:r
>> $B$h$m$7$$$G$9$+(B (Y/N)?y
>> $B=hM}%G%#%l%/%H%j(B: c:\
>>
>> C:\>xcacls c:\
>> c:\ BUILTIN\AdministratorsOI)(CI)F
>> NT AUTHORITY\SYSTEMOI)(CI)F
>> BUILTIN\UsersOI)(CI)R
>>
>> When I tried xcacls with the same parameters, it weirded the results
>> worse.
>>
>> Can anyone say how to restore it to this:
>> BUILTIN\AdministratorsOI)(CI)F
>> NT AUTHORITY\SYSTEMOI)(CI)F
>> CREATOR OWNEROI)(CI)(IO)F
>> BUILTIN\USERSOI)(CI)R
>> BUILTIN\USERSCI)(special access)
>> FILE_APPEND_DATA
>> BUILTIN\USERSCI)(IO)(special access)
>> FILE_WRITE_DATA
>>
>
>

I tried this command:
cscript xcacls.vbs c:\ /e /g users:32 /debug

It got as far as this:
SetACLForObject: Saving new Descriptor

The cscript.exe process is no longer using any CPU time, but wmiprvse.exe is
fluctuating around 5% to 25%. Are these processes related?

The downloaded program (installer) is named xcacls_installer.exe. Microsoft
tested the installer in one country. The installed program is named
XCACLS.vbs. I wonder if maybe Microsoft tested this program in one country
too? But what could it ......
Flash news report. It took 451.5469 seconds to run. It didn't hang, it
only looked like it hanged.

The result does not match the desired original results.

When Windows XP was originally installed and/or updated by SP2 or other
security fixes, C:\ gave these rights to BUILTIN\Users:
(OI)(CI)R
(CI)(special access
FILE_APPEND_DATA
(CI)(IO)(special access
FILE_WRITE_DATA

Now it has these:
(OI)(CI)R
(OI)(IO)(special access
SYNCHRONIZE
FILE_WRITE_DATA
FILE_APPEND_DATA

"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:eVzk1L4CGHA.2912@tk2msftngp13.phx.gbl...
> Thank you. But as far as I can tell, there's still no way to force
> combinations of (OI), (CI), and (IO) to be set the way they were supposed
> to be. The /I switch can be ENABLE or COPY or REMOVE but it can't be made
> specific enough.
>
> Anyone have XXCACLS.TXT.VBS? oops
> Anyone have XXCACLS.VBS?
>
> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> news:-sCdnYwTVc_0sS_eRVn-gg@comcast.com...
>> If you have not tried it yet take a look at using xcacls.vbs which is
>> more powerful and easier to use than the others. There are also free
>> third party tools like fileacl that you may also want to look into. ---
>> Steve
>>
>> http://support.microsoft.com/?id=825751 --- Xcacls.vbs
>>
>> "Norman Diamond" <ndiamond@community.nospam> wrote in message
>> news:Oh3tdIoCGHA.516@TK2MSFTNGP15.phx.gbl...
>>> As far as I can tell, normal permissions for a root directory (C:\) are:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> CREATOR OWNEROI)(CI)(IO)F
>>> BUILTIN\USERSOI)(CI)R
>>> BUILTIN\USERSCI)(special access)
>>> FILE_APPEND_DATA
>>> BUILTIN\USERSCI)(IO)(special access)
>>> FILE_WRITE_DATA
>>> Everyone:R
>>>
>>> (I translated the words "special access". If I mistranslated, here's
>>> what
>>> it really said:
>>> $BFC<l$J%"%/%;%9(B)
>>>
>>> The closest that I can produce is:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> BUILTIN\UsersOI)(CI)R
>>>
>>> I don't even know how I got it to come as far as (OI) and (CI). When I
>>> tried to specify these qualifiers in a CACLS command, it told me the
>>> meanings but it refused to obey.
>>>
>>> How can I give USERS the special access right of FILE_APPEND_DATA and
>>> make
>>> it (CI) only?
>>>
>>> How can I give USERS the special access right of FILE_WRITE_DATA and
>>> make it
>>> (CI)(IO) only? And what does the combination of (CI) and (IO) mean,
>>> since
>>> (CI) means it includes the current directory and subfolders but (IO)
>>> means
>>> it excludes the current directory?
>>>
>>> The way I got to this stupid position was that first I tried to use
>>> Windows
>>> Explorer's security tab to give one additional user a privilege to write
>>> in
>>> the C:\ directory, and Windows Explorer hanged. So I tried to use the
>>> CACLS
>>> command, which naturally deleted all privileges for users other than the
>>> one
>>> that I gave that new write privilege to. I'm not sure how I was able to
>>> partially restore the privileges to the three shown above, since I
>>> supposedly no longer had privilege to set privileges. Yeah from that
>>> experience I learned what the /E flag means.
>>>
>>> I've read http://support.microsoft.com/?kbid=318754
>>> which says there is no way to specify FILE_APPEND_DATA or
>>> FILE_WRITE_DATA
>>> because they're subsets of basic access rights, but I'm not a good
>>> enough
>>> guesser to guess which basic access rights these are. Which basic
>>> access
>>> rights are (CI) only, and which basic access rights are
>>> (CI)(IO)(whatever it
>>> means to both include and exclude the current directory).
>>>
>>> I've read the output of XCACLS /?
>>>
>>>> filename Displays ACLs.
>>>
>>> Yeah so when I want to set instead of display, I omit filename and it
>>> complains.
>>>
>>>> Spec can be the same as perm and will only be
>>>> applied to a directory. In this case, Perm
>>>> will be used for file inheritence in this
>>>> directory. If not omitted: Spec=Perm. Special values
>>>> for Spec only:
>>>> T Not Specified (for file inherit,
>>>> only for dirs valid)
>>>> At least one access right has to follow!
>>>> Entries between ';' and T will be ignored!
>>>
>>> If spec is the same as perm then it will only be applied to a directory,
>>> which in this case is C:\. In this case perm will be used for file
>>> inheritence. Now I'm lost again, is it only applied to the directory or
>>> is
>>> it only used for file inheritence? Or maybe really used for something
>>> else
>>> entirely?
>>>
>>> If not omitted: Spec=Perm. Really useful, that. If it is omitted then
>>> it
>>> can be used for ... No I give up. If not omitted then it's used for
>>> ... I
>>> got it, it applies to both the directory and for file inheritance
>>> because
>>> it's the same as perm.
>>>
>>> Well, omitting or not omitting, the closest I've come to making it
>>> correct
>>> is:
>>>
>>> C:\>cacls c:\ /g administrators:f system:f users:r
>>> $B$h$m$7$$$G$9$+(B (Y/N)?y
>>> $B=hM}%G%#%l%/%H%j(B: c:\
>>>
>>> C:\>xcacls c:\
>>> c:\ BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> BUILTIN\UsersOI)(CI)R
>>>
>>> When I tried xcacls with the same parameters, it weirded the results
>>> worse.
>>>
>>> Can anyone say how to restore it to this:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> CREATOR OWNEROI)(CI)(IO)F
>>> BUILTIN\USERSOI)(CI)R
>>> BUILTIN\USERSCI)(special access)
>>> FILE_APPEND_DATA
>>> BUILTIN\USERSCI)(IO)(special access)
>>> FILE_WRITE_DATA
>>>
>>
>>
>

Oh there's more.

http://support.microsoft.com/?id=825751
says:
> /P user:GUI Replace security permissions similar to standard
> choices.

cscript xcacls.vbs c:\ /e /p users:gui
says:
Error: Permission Code not recognized: G
Error: Permission Code not recognized: U
Error: Permission Code not recognized: I

Maybe the author of the program and the author of the Knowledge Base article
should have a meeting?

You can send feedback on a KB article if you want as shown on the right hand
side of any KB article. --- Steve


"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:%23vzDIj4CGHA.3980@TK2MSFTNGP12.phx.gbl...
> Oh there's more.
>
> http://support.microsoft.com/?id=825751
> says:
>> /P user:GUI Replace security permissions similar to standard
>> choices.
>
> cscript xcacls.vbs c:\ /e /p users:gui
> says:
> Error: Permission Code not recognized: G
> Error: Permission Code not recognized: U
> Error: Permission Code not recognized: I
>
> Maybe the author of the program and the author of the Knowledge Base
> article should have a meeting?

Maybe in this case you are better off configuring permissions via Windows
Explorer special permissions. For an AD domain you can use Group Policy file
system if you need to configure a large amount of computer though that is
best not done at the domain level. --- Steve


"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:eVzk1L4CGHA.2912@tk2msftngp13.phx.gbl...
> Thank you. But as far as I can tell, there's still no way to force
> combinations of (OI), (CI), and (IO) to be set the way they were supposed
> to be. The /I switch can be ENABLE or COPY or REMOVE but it can't be made
> specific enough.
>
> Anyone have XXCACLS.TXT.VBS? oops
> Anyone have XXCACLS.VBS?
>
> "Steven L Umbach" <n9rou@n0-spam-for-me-comcast.net> wrote in message
> news:-sCdnYwTVc_0sS_eRVn-gg@comcast.com...
>> If you have not tried it yet take a look at using xcacls.vbs which is
>> more powerful and easier to use than the others. There are also free
>> third party tools like fileacl that you may also want to look into. ---
>> Steve
>>
>> http://support.microsoft.com/?id=825751 --- Xcacls.vbs
>>
>> "Norman Diamond" <ndiamond@community.nospam> wrote in message
>> news:Oh3tdIoCGHA.516@TK2MSFTNGP15.phx.gbl...
>>> As far as I can tell, normal permissions for a root directory (C:\) are:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> CREATOR OWNEROI)(CI)(IO)F
>>> BUILTIN\USERSOI)(CI)R
>>> BUILTIN\USERSCI)(special access)
>>> FILE_APPEND_DATA
>>> BUILTIN\USERSCI)(IO)(special access)
>>> FILE_WRITE_DATA
>>> Everyone:R
>>>
>>> (I translated the words "special access". If I mistranslated, here's
>>> what
>>> it really said:
>>> $BFC<l$J%"%/%;%9(B)
>>>
>>> The closest that I can produce is:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> BUILTIN\UsersOI)(CI)R
>>>
>>> I don't even know how I got it to come as far as (OI) and (CI). When I
>>> tried to specify these qualifiers in a CACLS command, it told me the
>>> meanings but it refused to obey.
>>>
>>> How can I give USERS the special access right of FILE_APPEND_DATA and
>>> make
>>> it (CI) only?
>>>
>>> How can I give USERS the special access right of FILE_WRITE_DATA and
>>> make it
>>> (CI)(IO) only? And what does the combination of (CI) and (IO) mean,
>>> since
>>> (CI) means it includes the current directory and subfolders but (IO)
>>> means
>>> it excludes the current directory?
>>>
>>> The way I got to this stupid position was that first I tried to use
>>> Windows
>>> Explorer's security tab to give one additional user a privilege to write
>>> in
>>> the C:\ directory, and Windows Explorer hanged. So I tried to use the
>>> CACLS
>>> command, which naturally deleted all privileges for users other than the
>>> one
>>> that I gave that new write privilege to. I'm not sure how I was able to
>>> partially restore the privileges to the three shown above, since I
>>> supposedly no longer had privilege to set privileges. Yeah from that
>>> experience I learned what the /E flag means.
>>>
>>> I've read http://support.microsoft.com/?kbid=318754
>>> which says there is no way to specify FILE_APPEND_DATA or
>>> FILE_WRITE_DATA
>>> because they're subsets of basic access rights, but I'm not a good
>>> enough
>>> guesser to guess which basic access rights these are. Which basic
>>> access
>>> rights are (CI) only, and which basic access rights are
>>> (CI)(IO)(whatever it
>>> means to both include and exclude the current directory).
>>>
>>> I've read the output of XCACLS /?
>>>
>>>> filename Displays ACLs.
>>>
>>> Yeah so when I want to set instead of display, I omit filename and it
>>> complains.
>>>
>>>> Spec can be the same as perm and will only be
>>>> applied to a directory. In this case, Perm
>>>> will be used for file inheritence in this
>>>> directory. If not omitted: Spec=Perm. Special values
>>>> for Spec only:
>>>> T Not Specified (for file inherit,
>>>> only for dirs valid)
>>>> At least one access right has to follow!
>>>> Entries between ';' and T will be ignored!
>>>
>>> If spec is the same as perm then it will only be applied to a directory,
>>> which in this case is C:\. In this case perm will be used for file
>>> inheritence. Now I'm lost again, is it only applied to the directory or
>>> is
>>> it only used for file inheritence? Or maybe really used for something
>>> else
>>> entirely?
>>>
>>> If not omitted: Spec=Perm. Really useful, that. If it is omitted then
>>> it
>>> can be used for ... No I give up. If not omitted then it's used for
>>> ... I
>>> got it, it applies to both the directory and for file inheritance
>>> because
>>> it's the same as perm.
>>>
>>> Well, omitting or not omitting, the closest I've come to making it
>>> correct
>>> is:
>>>
>>> C:\>cacls c:\ /g administrators:f system:f users:r
>>> $B$h$m$7$$$G$9$+(B (Y/N)?y
>>> $B=hM}%G%#%l%/%H%j(B: c:\
>>>
>>> C:\>xcacls c:\
>>> c:\ BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> BUILTIN\UsersOI)(CI)R
>>>
>>> When I tried xcacls with the same parameters, it weirded the results
>>> worse.
>>>
>>> Can anyone say how to restore it to this:
>>> BUILTIN\AdministratorsOI)(CI)F
>>> NT AUTHORITY\SYSTEMOI)(CI)F
>>> CREATOR OWNEROI)(CI)(IO)F
>>> BUILTIN\USERSOI)(CI)R
>>> BUILTIN\USERSCI)(special access)
>>> FILE_APPEND_DATA
>>> BUILTIN\USERSCI)(IO)(special access)
>>> FILE_WRITE_DATA
>>>
>>
>>
>