Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

First up. PerlIO layers are definitely a part of this problem. Commenting out the binmode makes it go away (as you already know>).

But, it is (much) more complicated than that. At the point where the unlink fails, (at least) two processes are hanging on to handles to that file:

C:\test>junk44 Permission denied : The process cannot access the file because it is b +eing used by another process at C:\test\junk44.pl line 30. perl.exe pid: 17320 PB-IM2525-AIO\HomeAdmin : 60: File (RW-) C:\ +test\ttz cmd.exe pid: 17324 PB-IM2525-AIO\HomeAdmin : 60: File (RW-) C:\t +est\ttz handle.exe pid: 16152 PB-IM2525-AIO\HomeAdmin : 60: File (RW-) C +:\test\ttz
  1. perl.exe is the one running the script.
  2. handle.exe is the process that is doing this discovery.
  3. cmd.exe is (one of) the shell that was used to run the echo command to create the file.

    Further muddying the waters here is your prefixing the command you want to run with 'cmd /c'.

    Because the system code detects that you are using a shell metachar '>' in the command, it automatically prefixes the command you supply with 'cmd.exe /x/d/c'.

    So the actual command being run is:

    cmd.exe /x/d/c "cmd /c echo xx >$file"

    Doing away with that doesn't fix the problem, but it makes it less complex.

Also, running the command to create the file from within the script is confusing things and there is no need for it.

This simplified version of your script:

use strict; use warnings; my $file='ttz'; open( my $fh, $file ) or die "open error $!"; binmode( $fh, ':unix'); close($fh) or die "close error $!"; if( !unlink($file) ) { warn $!, ' : ', $^E; }

exhibits exactly the same behaviour when the file is pre-created:

## In a different session from which I will run my modified version of + your script C:\test>echo xx > ttz C:\test>handle | find "ttz" ## shows that immediately after creation, + nothing has an open handle to that file ## Now in the other session C:\test>junk44 Permission denied : The process cannot access the file because it is b +eing used by another process at C:\test\junk44.pl line 12. ## And back in the first session whilst the 10 second sleep is running C:\test>handle | find "ttz" 60: File (RW-) C:\test\ttz

Only one process has a handle to the file, and that process is Perl itself.

(Tentative) Conclusion: The error message is wrong, or at least, misleading. The "other process" that is preventing the unlink, is actually the same process that is trying to perform the unlink.

Essentially, the close has failed (silently), or has simply not been enacted, and so the unlink cannot proceed because there is an open handle to the file.

Tracking this further means delving into IO layers ... why did the close fail silently?


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Re: Win32: Setting a layer with binmode causes problem with close() on Windows (PerlIO silently fails to close the file) by BrowserUk
in thread Win32: Setting a layer with binmode causes problem with close() on Windows by rovf

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (4)
As of 2024-03-29 06:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found