UnstoppableDrew has asked for the
wisdom of the Perl Monks concerning the following question:

I am seeing a very odd behavior with ActivePerl 5.8.8 build 822, however I don't think it's specific to this build as I've seen similar problems in the past. It is however a Windows thing.

The problem I'm having is for no readily apparent reason, a subroutine call is being skipped over. In this instance it is File::Copy::Recursive::pathempty, but I've also seen this happen in other modules. It is only happening on one of a dozen identical systems.

I first noticed a problem when one of our in-house tools was throwing a lot of errors while using File::Copy::Recursive. I wrote a 2 line script to call pathrm on an explicitly specified path. I stepped into pathrm in the debugger, and when it called pathempty I tried to step into that, but it just skipped over the line. I put a print statement in pathempty and ran my script from the command line and it never printed.

I tried reinstalling perl, with no change. Can anyone offer a pointer of what else to look at, or an explanation of why this happens ?

I'm not a windows user, but I do know from experience that there can be subtle differences in the configuration settings for various apps (e.g. attributes for command-line shell windows) that people tend to ignore or forget about when they compare two windows machines and call them "identical".

Maybe this is just a red herring, but if one machine out of several behaves different, it seems inaccurate to call it "identical" to the rest, and it might be worthwhile looking for the thing that makes it "not identical" (OS-patches/config/app-parameter-settings/etc...), rather than looking at just the perl code that triggers the deviant behavior.

Ok, this is what I get for assuming other people can write code. mr_mischief was correct, the calls to pathrm were not using the second argument to force the call to pathempty. My bad for not re-reading the docs. Makes me wonder how this ever worked, as the return value of pathrm was not being checked so every call to delete a directory was silently failing and being ignored. Now that I'm done chasing that red herring, perhaps I can solve the original problem.

This one server has been throwing the error:closedir() attempted on invalid dirhandle PTH_DH at C:\Work\trunk\3pty\perl\lib/File/Copy/Recursive.pm line 318.

After some extensive time in the debugger, here's what seems to be happening:

pathrmdir calls pathempty, which opens the directory and iterates over the items, calling unlink for files and pathrmdir for directories. At some point it hits a directory, the sole content of which is an empty directory . pathrmdir calls pathempty which calls pathrmdir which calls pathempty, which does nothing and returns. pathrmdir calls rmdir on the empty directory and returns. Back in pathempty it tries to close the dir handle and exits with code 9.

I think these functions need to localize the dir handle it's using, I'm surprised this doesn't come up more often. I have just reproduced it using the following:

Ok, this is what I get for assuming other people can write code. mr_mischief was correct, the calls to pathrm were not using the second argument to force the call to pathempty. My bad for not re-reading the docs.

Actually, this is what you get for assuming someone else takes the time to write your code for you when you didn't take the timeand make the effort to post what you had first. If you're having an issue with the length of that statement, just remember the words in bold. They make a sentence all their own.

Troubleshooting code from a prose description of the problem without the source that's causing the problem is like a doctor trying to diagnose an illness from described symptoms without a fluid sample from the patient.

Consider yourself lucky someone spent the time to diagnose your problem from the docs without seeing what you were doing.