As has already been pointed out by Skeeve, you're not reading in the data there before you start incrementing the results.

It's also a very good idea to lock the results file before you write to it - especially with web applications - otherwise you could find that the file gets clobbered and you lose the data in it.

I've always done this using Fcntl's flock method, which can be set to only allow one process read/write access to a file at a time.

It seems most effective (from experience) if you use flock on a lock file, and lock that, rather than the results file directly before you write any data. For example:

use Fcntl qw/:flock/;

open  LOCK, ">", "results.dat.lck" or die;
flock LOCK, LOCK_EX;

open  OUT, ">", "results.dat" or die;
# print data
close OUT;

close LOCK; # releases the lockfile, lets other processes write
[download]

I'm sure this is documented somewhere in a much better way than I can explain it, and with the reasons behind the use of the external lock file rather than direct locking, but I can't find it at the minute. I'll keep looking .. *grin*

Hope that helps.

-- Foxcub
#include www.liquidfusion.org.uk