Perl under windows: mysteriously skipping over subroutine

[UnstoppableDrew]

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 ?

Thanks!

[mr_mischief]

What is the value of $force when pathrm() gets to the line pathempty($cur) if $force;?

If the condition is false (numeric zero, undef, or the empty string for example), then the call won't be made.

The docs for pathrm() state "An optional second argument makes it call pathempty() before any rmdir()'s when set to true.", so you might want to check and make sure that argument is present and true.

See also $File::Copy::Recursive::RMTrgFil for more ifno on why things might not be what they seem.

Posting some code you've tried might help us help you. Reading some docs and code might help you help yourself.

[Fletch]

Well, going by the succinct code sample you helpfully provided which exhibited this problem you can easily see the problem's on line 17.

[graff]

It is only happening on one of a dozen identical systems.

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.

[UnstoppableDrew]

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:

For a directory that looks like this:

C:\TMP\PATHTEST
|--bar
   |--baz

where baz is the only thing in bar, and baz is empty, using this code:

perl -e "use File::Copy::Recursive qw(pathrmdir); pathrmdir('pathtest'
+,1); print qq(done\n);"

the output is:

closedir() attempted on invalid dirhandle PTH_DH at c:\trunk\3pty\perl
+\lib/File/Copy/Recursive.pm line 318.
closedir() attempted on invalid dirhandle PTH_DH at c:\trunk\3pty\perl
+\lib/File/Copy/Recursive.pm line 318.
done

And that's on a different pc than the one originally showing the problem. I will try localizing the dir handle and see what happens.

[UnstoppableDrew]

Bingo! Adding 'local(*PTH_DH);' to pathempty() fixes it. Thanks for the nudge in the right direction to look.

[mr_mischief]

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 time and 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.

Now, you have a completely different problem to solve which someone might have solved for you the first time around had they been able to see your code. Help us help you. How (Not) To Ask A Question and Why Questions Go Unanswered (Thanks, Dominous!) might help you to help us help you.

If you really want someone else to write the code from scratch instead of helping you with a specific issue you're having, there's always http://jobs.perl.org.