Ahh, thanks for finding that. It's a misunderstanding on my part about how File::Find works. I was presuming that _ was always correct, and apparently, it's not. I'll have File::Finder do a single lstat($_) before calling the step chain then. That'll cure it, and you can simulate that right now with:
my $steps = File::Finder->eval(sub{lstat})-> ...;
and you should see proper results then.
update:
The fix for your bug is in version 0.02, along with the ->comma step to emulate GNU-find's comma operator. Now blasting to CPAN mirrors near you. | [reply]
[d/l]
[select] |
And now you've joined the huge throng of those who have had their scripts made slower by this File::Find "optimization".1
Instead, set $File::Find::dont_use_nlink = 1 and go back to using _ and your module will no longer produce two calls to stat/lstat per file much of the time.
You could make sensible use of this optimization in your module since you can tell whether the files are being selected only based on their names. But File::Find should really only use this optimization in the few cases when it is useful, based on the user asking for that optimization.
1 I don't much mind the speed penalty of often doing two stat/lstat calls per file, but I do mind it being caused by something claiming to be an optimization, especially when that optimization is responsible for breaking so much code, including the first version of a module sent to CPAN by merlyn (if merlyn, long advocate of File::Find, got caught by this in published code, surely many, many other people have lost time due this supposed time-saver).
| [reply]
[d/l] |
