Hello, I did implement your suggestions, and the permissions from stat came back 0x0777, which I'm pretty sure means I should have proper permission to rename.

I did find something interesting using the debugger. I put a breakpoint in just before the rename occurs, and using unlocker (http://ccollomb.free.fr/unlocker/) I can see what processes have a lock on the directory. When using the older version of perl, no lock showed up when at the breakpoint. However, using the newer version, "perl.exe" shows up as having a lock on that directory.

Turns out I need to use "closedir" rather than "close" when obtaining the directory listing above. Problem solved.

++ for tracking this problem down and for reporting your findings here. Perhaps it will help someone out in the future.

By the way, I went back and analyzed your code using perlcritic, hoping that it would detect and report an opendir without a matching closedir. No luck -- at least not with its default settings. Perhaps it can be configured to catch this type of situation.

I believe this problem can be averted using the File::Slurp module from CPAN. Its read_dir function automatically opens and closes a directory. Furthermore, it checks if the open was successful (which your code does not do). Finally, it excludes . and .. by default.

use File::Slurp qw(read_dir);
my @entries = read_dir($InDir);
[download]

Also, the rename doc mentions that File::Copy::move might be a more portable alternative.