in reply to Can't open($newfh, $mode_layers, '&' . fileno($fh))

1) How can I get the open()'d modes for a filehandle on Win32 ? fcntl() doesn't work there, and I can't seem to find a Win32 module to do it...

From what I can tell, this isn't a Win32::API problem, more a CRT problem as the rules regarding open modes are imposed/enforced by the CRT (or possibly the PerlIO layer if you're using that).

There does not appear to be anything in the VC++ CRT library for retrieving the open mode from an existing open file. Once you've dup()'d a file, you have to associate it with a FILE* stream, and Perl's open does not provide a mechanism for doing this without also supplying the mode--probably because there is no mechanism in the CRT for re-constituting a stream with it's original mode.

About the best you could do is use '+>' and position the pointer at the end-of-file to cater for an original append mode and hope/assume that if the user wishes to read from or write to any other position in the file, they will do a seek first.

This leaves one hole in the logic. If they originally opened it '+>>', the docs say that all writes will go to the end of file regardless of whether there have been intervening reads at other positions. If the programmer is relying on this behaviour, (he's probably unwise if he does), then he could be caught out.


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.
  • Comment on Re: Can't open($newfh, $mode_layers, '&' . fileno($fh))

Replies are listed 'Best First'.
Re^2: Can't open($newfh, $mode_layers, '&' . fileno($fh))
by renodino (Curate) on Feb 11, 2006 at 18:23 UTC
    After a solid 8 hours spent chasing this issue (and the other issue RE: mixing layers and fileno open()'s), I've come to a similar conclusion. So I've thrown in the towel on trying to transparently marshal handles between threads.

    While not a catastrophic loss (since app-specific marshalling is always possible), it is a frustrating situation. I suppose a heavyweight solution might wrap handles in their own apartment thread, and proxy all the operations (ala DBIx::Threaded), but I reckon there be dragons there as well...