You can't or its very hard to debug cgi w/o access to the webserver's error log, so when you say "it didn't work" you should be sure (and say) there's nothing in there. Sprinkling a bunch of 'print STDERR' lines in the code (in my favorite format, my $debug = 30;):

for ($loop=1; $loop <= $form{'files'}; $loop++){
        if ($form{"img$loop"}){
print STDERR "in if: form var img${loop} is $form{img${loop}}\n"
  if $debug > 15;
...
print STDERR "done mussing: form1 img$loop is $form1{img${loop}}\n"
  if $debug > 10;
print STDERR "opening: form filename is $form{filename}\n"
  if $debug > 20;
open(FILE, ">$form{'filename'}/$form1{\"img$loop\"}") 
  or die "can't open ", "$form{filename}/$form1{img${loop}}", ": $!";
while ($bytesread=read($file,$buffer,1024)) {
print STDERR "while: read $bytesread\n" 
  if $debug > 20;
[download]

You also seem to be unsure of the hash syntax; you don't need single quotes for constants: e.g.
$hash{'this'} eq $hash{this};
and, if you're mixing a var in a string ("img$loop") a good idea is to use the curly brackets to be sure it gets handled (and to make it apparent to the humans; "img${loop}" So:
$hash{"img$loop"} eq $hash{"img${loop}"}
but clearer/safer/cleaner is:

my $this_loop = "img${loop}";
$hash{$this_loop} = ...
[download]

Doesn't cost you anything, code is more readable and its easier to use/debug, just print $this_loop or:

my $img_file = "$form{filename}/$form1{$this_loop}";
open(FILE, ">$img_file") or die "can't open $img_file: $!";
[download]

Do this, look through the error log and then you can confidently say 'its not working' ... probably, though, you'll see something useful in there. Oh, if its a busy server, prefix all the print STDERR msgs w/ "my_cgi: ..." so they'll stand out in the log. And when it works, my $debug = 0 makes them all go away.

Update:Are you using (and if no, why not!? ;-) cgi.pm? It does the upload for you (search on cgi upload sysread) if you're using the upload stuff, so sysread won't find anything to ... well read. 'course, that means all that debugging would be for naught, but still its good practice. Sort of that "set a monk on fire" idea (hmm, bad connotations there, sorry).

a