I can think of two ways a read from a successfully opened file could fail:

Opening a file for write access and then trying to read from it. Perl catches this.

Opening a file on removeable media, and then the media is removed before the read attempt.

Under win32 (native), this results in an "Abort, retry, continue" popup. Retry is loop unless it is reinserted. The other two result in the read completing as if the file where empty. Ie. a successful read of zero bytes. I'm not sure what *nix would do under these circumstances.

You forgot about corrupted media. The cheapest media to corrupt is CD-Roms. Take 1, burn a giant file to take up all the space, then scratch it, then try reading from it.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

I'm thinking more along the lines of an NFS or Samba mount that goes bye-bye

+++++++++++++++++
#!/usr/bin/perl
use warnings;use strict;use brain;

Very true, we've been discussing that here - more like, well, if it 'very rarely' happens, should we try to catch a failure.

But seeing as we have code that tries to deal intelligently with this scenario, we really should try and test it, just to confirm the code really does what we think it does.

So yes one solution is to not cater for read failures on successfully opened files - then you dont need a test case !-)

But we are (currently) catering for it, and we want to test that accomodation on different platforms - but with the above mentioned difficulty.

FWIW, we are getting a consistent (as in, the same error message) on Linux and Solaris if we replace the dummy directory handle (made with IO::File) with one created by IO::Dir - we get

'usage: $dh->seek(POS) at ...'
[download]

I suppose you could create the file, open it successfully, then delete it and try to read from it. That might generate a read error.

Not on UNIX. It is perfectly possible to open a file, unlink it from the file system, and still be able to read from or write to it. The file is actually deleted when the last open filehandle to it is closed. This is a common way to create a temporary file that no other process can open.

#!/usr/bin/perl

my $tf = 'tmpfile';

open FH, ">$tf" or die $!;
print FH "Test data\n";
close FH;

open FH, "<$tf" or die $!;
unlink $tf;
print "File deleted!\n" unless -e $tf;
print 'File contents: ', <FH>;
[download]

In a similar way, removing read permissions on a file won't prevent reading of the contents through an already open file handle. That may seem insecure, but the property can be used to enhance security. If a process needs to read from or write to a protected resource, it can start life as root, open the resource appropriately and then drop privileges. The now unprivileged process still has privileged access through the open file handle.
"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

What on earth would generate a read failure?

Networked file systems, corrupt media, broken pipe, etc. Not checking for read errors can lead to evil bugs :-)

As to the OPs question:

... can anyone advise me on a better way for testing cross platform read failures?

I find redefining read is the simplest solution. At its most basic just adding

BEGIN {
    *CORE::GLOBAL::read = sub (*\$$;$) { return undef };
};
[download]

to your test file will always cause read to fail.

Yep, of course.
And nicely extensible to other functions in the CORE package I imagine, like testing failing write()'s, etc.

That is the solution I will use.

Thank you

+++++++++++++++++
#!/usr/bin/perl
use warnings;use strict;use brain;

Bugger, that doesn't work, and it behaves funny too.

Here's the code in the File.t file

...
$file = File->new('t/file7.test');

eval {
    # declare as local so default is restored on block exit
    local *CORE::GLOBAL::read = sub (*\$$;$) { return undef };

    $file->header();
};
...
[download]

And File::header() looks like this

...
sub header {
    my ( $self ) = @_;

    my $seek_rc = $self->{FH}->seek($self->{Header}->{OFFSET}, SEEK_SE
+T );

    if ($seek_rc == 0) {
    croak( 'Cannot seek to absolute file position on opened file handl
+e - ', $! );
    }

    my $length = $self->{FH}->read(my $header, $self->{Header}->{Lengt
+h});

    # check if read() had an error
    croak( "Error in reading file header - $!") # pathological test
      unless defined $length;

    croak( 'Error in reading file header - Mismatch between expected l
+ength (', $self->{Header}->{Length}, ") and returned  length ($length
+) byte count")
      unless $length == $self->{Header}->{_Length};

    $header =~ s/(?:\015+)?\012.*$/\n/;   # remove any garbage at end 
+of header and replace with \n

    return $header;
}
...
[download]

So if the read() returns undef, I expect the croak() message to appear with the $! reason for failure.

Instead, I don't get my croak() message , all I get is $! populated with 'Bad file descriptor'. $@ is empty (that us , $@ eq '').

Whatsmore, this happens on Linux. Both $@ and $! are still an empty string on Solaris.

So why aren't I croak()'ing ?

use brain;