Yep. You never chomp the data read from the filehandle FILE. Since you are building the file name directly from the line read, it most likely contains a newline. If you print your value for $line with a delimiter surrounding it (print "'$line'\n";) you will see what I mean. See chomp (as has been previously mentioned) for a solution.
Update: Since the OP is using $& to populate the hash, and the processing loop uses the keys of the hash as the name of the file, the newline from the file should not be included in the hash key. Nice catch choroba
I wonder what the line endings are in the data file. Is it possible that the file is in DOS line ending format? In which case, the chomp (and $&?) would not do the right thing.
It's a bit more complicated. The OP uses $& as the hash key after matching />.*/, which removes the newline (as . does not match a newline), but it can overwrite a previous hash value if the line does not match, which we cannot tell without seeing the input data.