Re^4: Win32: Setting a layer with binmode causes problem with close() on Windows (PerlIO silently fails to close the file)

[rovf]

So, the fact that system has returned does not mean all of it resources have been cleaned up.

Oh my! I didn't think about this issue! But this would mean that it is unsafe to have an (external) process create a file, and then use it in my program - at least under Windows, which is very picky about this kind of stuff? If I understand you right, this should even true if we use IPC::Run to run the process. OTOH, this scenario - running an utility to create a file, then use it - is so common, that I wonder why we are not bitten by this more often. Or is there a clever, safe way to achieve the goal?

[BrowserUk]

I didn't think about this issue! But this would mean that it is unsafe to have an (external) process create a file, and then use it in my program - at least under Windows, which is very picky about this kind of stuff?

Here's the thing. If you want to delete a file that you've been accessing, from the script you've been accessing it from, you need close it first. If you've also run some commands via system that accessed that file, and they have left open, duped handles in the kernel, they will disappear as soon as you close your handle.

So normally, the problem does not arise. Indeed you can verify this by running your OP code with the binmode commented out.

It was only necessary to remove all the subprocesses from your example in order to confirm, by dint of 'it couldn't be anything else', that is was the perl process that was holding the open handle.

It then becomes clear that the "other process" is actually 'this process'; and thus the close is failing silently when binmode has added the ':unix' IO layer to the stack.

[Anonymous Monk]

something like this

sub system_detached {
    my $program;
    my @args ;
    my $cmdline;
    if( @_ > 1 ){
        ( $program ) = @_;
        $cmdline = Win32::ShellQuote::quote_system_string( @_ );
    } else {
        ( $cmdline ) = @_;
    }
    
    $!=$^E=0;
    my $ProcessObj;
## http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=
+vs.85).aspx# CreateProcess function (Windows)
## http://msdn.microsoft.com/en-us/library/windows/desktop/ms684863(v=
+vs.85).aspx# Process Creation Flags (Windows)
    
    use Win32::ShellQuote();
    use Win32::Process();
    
    Win32::Process::Create(
        $ProcessObj,
        $program,
        $cmdline,
        0, # don't inherit handles
        Win32::Process::DETACHED_PROCESS(),
        ".", #cwd
    ) or do {
        my $err = int($!).' '.$!." #### ".int($^E)." $^E  ";
        warn "??CreateProcess failed (\$ProcessObj $ProcessObj) $err "
+;
        return;
    };
    return $ProcessObj;
}

[BrowserUk]

Completely redundant and unnecessary.

[Anonymous Monk]

Completely redundant and unnecessary.

For this :unix issue, yes, probably, not for generic detached, system 1,... can be blocking