in reply to Learning Perl Chap 2 Win32::FileSecurity Help

Error 32 in ERROR_SHARING_VIOLATION which is probably a "valid error" in as much as it's something you might expect to encounter and either attemptto recover from or ignore.

It shoudl be being reported to you via a null return from Win32::FileSecurity::Get() and by the error text in $! per the documentation. Unfortunately, there appears to be a deliberate error in XS code that is causing it to croak instead of just reporting it back to the caller. When an error return is received from an OS API call, the XS code calls this routine to handle it. 

void
ErrorHandler( const char *ErrName ) {
    dTHX;
    SV* sv = NULL ;

/*    sv = perl_get_sv( "!", TRUE ) ; */
    if ( sv == NULL ) {
        croak( "Error handling error: %u, %s", GetLastError(), ErrName
+ ) ;
    } else {
        sv_setpv( sv, (char *) ErrName ) ;
        sv_setiv( sv, GetLastError() ) ;
        SvPOK_on(sv) ;
    }
}

[download]

It is meant to get access to $!, fill in the error text, and then return to the caller for recovery; but as you can see, the attempt to get access to $! has been commented out, so sv will always be null, and all error returns will croak. You should raise a perlbug.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Learning Perl Chap 2 Win32::FileSecurity Help ($^E)
by tye (Sage) on May 09, 2006 at 17:15 UTC

    The code is probably commented out because it would't work. $! is magical and so setting its value in that way would have no effect (similar to how the data stored in a scalar is ignored while the scalar is tied).

    The proper approach would be to just call SetLastError(...) which makes the error information available in $^E (which might not have been the case when this module was written).

    - tye        

[reply]

      Fair enough. Though inserting return would make more sense than always croaking.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
Re^2: Learning Perl Chap 2 Win32::FileSecurity Help
by punklrokk (Scribe) on May 09, 2006 at 15:58 UTC
    Woah,

    Little over my head there, but I think what you are saying is the Error Handler should grab Error $!, but because this is commented out, it just gives this generic error?

    JP Bourget (punklrokk) MS Information and Security Rochester Institute of Technology Rochester, NY
[reply]

      Kind of. The line commented out is meant to get access to the perl variable $! so that it can assign the error code and text into it (the else branch of the if statement), so that these will be available to the calling application.

      If it successfully obtains access to $! and takes the else branch, then the sub returns to it's immediate caller (other XS routines within the module), where those subs would then return undef or whatever to the calling application. The calling application (ie. your code), can then decide whether the error is something that it can saftely ignore and continue or abort as fits the purpose of the application.

      As it currently stands (on CPAN), any API error passed into ErrorHandler() is always fatal which is a nonsense. It's hard to guess why that would have been commented out or by whom--it looks like it was a quick check that got forgotten to me. Whatever, it should be corrected which means someone should raise a perlbug against it.

      As a workaround, though not a particularly satisfactory one because it means you will effectively be ignoring all api errors, you can use an eval block to trap the croak some thing like this: 

      use File::Find;
use Win32::FileSecurity;

#determine the DACL mask for Full Access
my $fullmask = Win32::FileSecurity::MakeMask('FULL');

&find(\&wanted,"\\");

my %users;

## Note: use return not next from a subroutine
## with warnings enabled perl will remind you of this
sub wanted {
    # Win32::FileSecurity::Get does not like the paging file, skip it
    return if ($_ eq "pagefile.sys");
    return unless -f $_;

    ## Do the get in an eval block and return 1 if it succeeds.
    ## Otherwise ignore the problem and go onto the next file.
    return unless eval{ Win32::FileSecurity::Get($_, \%users); 1 }; 
    return unless defined $users{"Everyone"};
    return unless $users{"Everyone"} == $fullmask;
    print "$File::Find::name\n";
}

      [download]
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        I kind of see where you're going with this, but the scope is a little over my ability. I read the eval page, but still lost.

        You are saying I can force Perl to grab the error, and if one exists, ignore that file? (case?)

        If so, how can I implement this in code? Is this a general error? Or just with EVERYONE? Or just with the FileSecurity mod?

        Thanks for your in depth feedback, I really appreciate it.

        JP Bourget (punklrokk) MS Information and Security Rochester Institute of Technology Rochester, NY
[reply]

In Section Seekers of Perl Wisdom