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

This is a very interesting suggestion. And, the program IS running on Linux machines. Do you know if there are analogous problems in the case of reads (you talked about problems with writing, which I am not doing)? And, is there any code for suppressing that condition analogous to your "sync" command for writes?

Of course, though this might illuminate my current problem, it does not solve the more general question: How does a Perl program discover that readdir could not execute correctly due to, for example, a hardware disk error?