Expanding on GrandFather's answer, the problem here is that wanted is a globally accessible name, which is defined in the lexical scope of a single call to findfile. There will therefore be only ever be one wanted function that will only see one lexically scoped $target. So the second, third, and later times you call findfile, wanted will not see the private values of $target set on those calls.

If this confuses you, see the code example at Re (tilly) 9: Why are closures cool? to see the issue at work.

On an unrelated note, once you resolve that bug you will have an even more mysterious one that Perl is not giving you a warning about. The problem is in the line

(my $foundfile = $File::Find::name) if $File::Find::name =~ $target;
[download]

It looks innocuous, but the problem is that my has both a compile time and a run time effect. What run time effect, you say? Well as an optimization, Perl does not actually clear lexical variables when you leave a function. Instead if possible it will reinitialize them when it encounters them again. (This is generally faster.) The problem is that in the pattern:

my $foo = $bar if condition();
[download]

if condition() is false, then my $foo is not executed, and Perl does not reinitialize your data.

The result? If your condition ever matches, you will continue to return that file name until the next time the condition matches at which point you will return the new file name until another one matches, etc.

The fix is to never, ever, ever put a my where it can be hidden by a conditional. In this case you would avoid it with:

my $foundfile;
$foundfile = $File::Find::name) if $File::Find::name =~ $target;
[download]

See Unusual Closure Behaviour for further discussion.