in reply to Testing for readdir failure

Hmm ... I have problems to simulate such a problem, so my theoretical advice is to use a block eval to catch a potential error.

And I wouldn't be surprised if $! also holds some informations, i.e. would be set in case of failure.

Cheers Rolf

( addicted to the Perl Programming Language)

update

OK, I tested to read from a directory which was deleted in the meantime, with mixed results, sometimes the error was catched, but sometimes not ???

use strict;
use warnings;

$|=1;
my $dh;

sub tst {
  my $flag=shift;

  print "\n\n-----";
  print "Provoking error\n" if $flag;
  
  mkdir "/tmp/bla";
  sleep 1;
  opendir $dh, "/tmp/bla" or die "$!";

  rmdir "/tmp/bla" if $flag;
  sleep 1;


  eval {
    print scalar readdir($dh);
    warn "--- $!" if $! and $! !~ /^File exists/;
  };
  warn "--- $@" if $@; 
}

tst($_) for 1,1,0,0;

[download]

update

consider also catching warnings with $SIG{__WARN__}

Replies are listed 'Best First'.
Re^2: Testing for readdir failure
by Zzenmonk (Sexton) on Apr 24, 2013 at 08:43 UTC

    Hi,

    Please notice the IO operations are not written directly to the disk, but to various levels of cache. With respect of the amount of directories processed, the origin of the issue might not even be in PERL but in the operating system and the way the disk snapshot are refreshed. This would explain the mixed result. I experienced this kind of problems on MS system.

    K

    The best medicine against depression is a cold beer!
[reply]
      Sure, but IMHO a cache should be transparent.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

[reply]

        Definitely! My issue looked very similar and was the result of a bug in the "fsflush" process (name of the process in Solaris). This process flushes all buffers to the disk. It is also responsible to provide a consistent snapshot of the disk + buffers state via an API to the other components of a system.

        I currently have a similar issue on a Linux box. The mixed hard disk snapshot is not always consistent. Sometimes the buffers are not properly flushed to the hard disk and I loose the solid state part of the storage. This matter has the same behavior as this case: no error at all at any level.

        So provided you have a unix box try the following: 

        # Prior to any opendir() statement issue:
system("sync");
# This will flush all buffers to the disk and refresh the disk snapsho
+t
# Next issue your opendir statement
opendir(...);
# Start your processing

        [download]

        If your issue disappears it is most probably an OS problem and PERL can not really help but you have a solution.

        K

        The best medicine against depression is a cold beer!
[reply]
[d/l]

In Section Seekers of Perl Wisdom