This can easily happen when Perl buffers some data instead of flushing it to disk. A second file handle opened to a file can't see that buffered data. Your solution of using lexical filehandles won't solve every case, for example the following:

sub write_stuff {
    open my $fh, '>>', $logfilename or die "Can't append to '$logfilen
+ame': $!";
    ...
    check_stuff();
    ...
};

sub check_stuff {
    open my $fh, '<', $logfilename or die "Can't read '$logfilename': 
+$!";
    while (<$fh>) {
        ...
    };
};
[download]

(also see Suffering From Buffering)

If one of your example functions calls the other, or threads are being used, that might happen, yes. If not, it's not allowed to happen.

From perldoc -f close:

Closes the file or pipe associated with the file handle, returning true only if IO buffers are successfully flushed and closes the system file descriptor.

So if the closing was successfully (and it usually is, unless the disk is full or something really evil happens), the buffer has to be flushed. If not, it's a bug.

Only if you use lexical variables as file handles. If you use open HANDLE, '>', $file;, then HANDLE is a global that doesn't go out of scope.

Ah, I didn't realise this, thank you (I'm not yet quite on top of typeglobs(?)). In reality there are a lot of different subs writing to that file---I thought I had checked them all for terminating close()s, but perhaps I've missed one... What I'm doing should be fairly simple, so I doubt I've found a long hidden bug.. much more likely to be a mistake on my part. I'll check it out :)

thanks