Even getting it to print the dots, as in an earlier post, was an abuse of the module. It was a trick that worked for that purpose because it turns out that dircopy uses fcopy, so even though dircopy doesn't expose its recursive method, overriding fcopy was a way to hook into the module's mechanics.

Now you're trying to bolt even more functionality into a module that really wasn't designed with extensibility in mind. Your best hope is to study the source code of that module to discover if there is any other point in the module's operation where you could hook in using the sub wrap trick again. If you get lucky you'll find that dircopy is calling some function with enough information for you to grab the current filename. As a matter of fact, it probably is possible by using a "before" sub using that Hook::WrapSub technique, and examining the contents of @_. You should do this yourself, because it will be a good learning exercise, even if you are using it to introduce some spooky action at a distance to your dircopy calls. But we shouldn't deprive you the opportunity to study and learn the source code, and come up with a solution.

If you recall from an earlier post, I used Hook::WrapSub. That may still be useful if you are using File::Copy::Recursive (I'm assuming you've abandoned File::Find now, but it's getting confusing following what you're doing). Study the source code for File::Copy::Recursive, Figure out where you can hook in using Hook::WrapSub, create a 'before' or 'after' sub (probably before, in this case), use Data::Dumper, and dump the contents of @_ so you can see what gets passed into the sub you are wrapping. That will help you know if you will be able to find a source filename or directory name.

I do want to mention again, outputting dots was your original request, and I showed how to make that happen. It's a bit of an ugly hack, but it worked. There's nothing about it that I would consider a best practice. I wouldn't want to find that in "production code", for example.