#29867: Win32::FileSecurity::Set fail on some localised system

I am using the Win32::FileSecurity perl module to get and set ACL on files

Using Win32::FileSecurity module on a german system I get the following
error

NT-AUTORIT-T\SYSTEM
Error handling error: 1706, LookupAccountName at foo.pl
line 120.

The source code of my test is as simple as
----->
use Win32::FileSecurity qw (Get Set);

Get("C:\foo.txt",\%hash);
Set("C:\foo.txt",\%hash);
----->


On a localized system the Win32::FileSecurity::Set() call is failing due
to a wrong interpretation of translated "NT AUTHORITY" string

looking at FileSecurity.c between line 500 and 530
the user names passed in the ACL hash are parsed to removed
well known domain part (LOCAL, NT AUTHORITY etc...)

these values are hardcoded with English version

see FileSecurity.c:100
static char *szLocalLookup[] = { "BUILTIN", "NT AUTHORITY", NULL } ;

for instance on a German system the system account , "NT
AUTHORITY\System" is called "NT-AUTORITÄT\SYSTEM"
see http://blogs.msdn.com/michkap/archive/2006/12/01/1183198.aspx for
all possible translations.

such parsing should not be performed on username set in the hash.

Emmanuel Jannetti wrote:
> I've logged bugs quite a long time ago against Win32::FileSecurity.pm
>
> #29869 : FileSecurity::Set does not handleLookupAccountName correctly
> #29867 : Win32::FileSecurity::Set fail on some localised system
>
> When I look at bugs opened against libwin32 I see that majority of
> them are 1 year old or even more. Looking at the documentation I see
> that the last update has been made in 1998.
>
> I see no activity around the bugs I've logged
>
> I am so wondering is this module is still maintain or not and if not
> what is the alternative ?.

I have to apologize for not making any libwin32 releases including your
bug fixes. It has been difficult to find the time to fix up *all* the
bundled modules at the same time to make an up-to-date release, so I
essentially only made the minimal changes necessary to keep things
working properly with the latest core Perl changes.

The only way around this dilemma seems to me to release the modules
individually to CPAN, and then replace libwin32 with a Bundle::libwin32
module that just requires all the individual modules as prerequisites.
This is already the case for the Win32, Win32API::File and
Win32API::Registry modules, which are either part of core Perl now, or
are maintained independently on CPAN.

On the bright side, I've just started over the last few weeks to import
all the old tarballs from CPAN, Backpan and other places I could find
into a subversion repository on code.google.com:

http://code.google.com/p/libwin32/source/browse

I hope to be able to make the individual releases within a week or two
(adding correct META.yml files, making sure only valid tests are being
run by `make test` etc). After that I can make updates to individual
modules without having to worry about open issues with any of the other
ones.

I plan to move the issue tracking from rt.cpan.org to code.google.com
as well, but haven't set up the categories etc. yet.

> Note that I've provided fix proposal in  #29869 and #29867. These
> fixes seems to work fine for now in my program.

I'll try to include your bug fixes in the initial release of the separate
Win32-FileSecurity module.

Again, I apologize that this has taken so much longer than it should
have!

Cheers,
-Jan