Viewing Thread:
"Hit counter problem (php)"

Hi,

I have a home-made php script that counts visits to my home page. It uses a simple text file to keep track. Problem is, twice recently, the counter has reset to zero, and started to build up again from there.

The counter script (see below) opens the text file, and uses flock() to try to lock the file. Then it adds 1, truncates the file to length 0, writes the counter and closes the file.

It also checks for the presence of a 1 hr cookie, so that it doesnt count returns to the page by the same person within that hour.

So ... why do I get reset to zero? Either someone's found out how to hack the file, or its to do with more than one user visiting at the same time, and the locking isnt working.

Any ideas, please?

$addone=1;
if (isset($visitor_ip)) $addone = 0;
$cfile = fopen("filename.dat", "a+");
$locked = flock($cfile,LOCK_EX);
rewind($cfile);
$vcounter = fgets($cfile, 255);
if (empty($vcounter)) {
$vcounter = 0;
$addone = 1;
}
$vcounter+=$addone;
if ($addone==1) {
setcookie ("visitor_ip", "addedone", time()+3600);
ftruncate($cfile,0);
fputs($cfile, $vcounter);
}
fclose($cfile);
?>

Right, so I've updated my counter script now. The counter got reset to zero again even with my separate lock file. I'm kinda suspicious that someone's able to hack into it. But then why would they bother?

So my new script opens the file as "a+", rewinds and gets the current counter. If the result is blank, then I can only assume that the file's just been truncated by another client. So I tell the script to sleep for 500ms and try again. I allow it to do this three times before it just returns a counter variable of "lots" rather than any number, and in this case it doesnt go on to update the file.
If the counter was not blank, then we add one, truncate the file to 0 length and write the new value back.

So far, so good. When I did a trace of visiting browsers recently, I found that I get a fair number of spiders, webbots and what have you, and I wonder whether they're the ones that mess up the counter. I suppose they shouldnt be counted anyway, to be fair, all I'm really interested in is living breathing visitors. Still - to exclude them would make it even more complex.

Nimco - if I get more problems, I'll get you to send your source over. Thanks for the offer.

doc693 wrote:
> Turbo - have you never had the problem where the counter resets to
> zero, then? One of my sites has suffered this at least three times,
> and the other one once as well (using the same script).

Nope, principally because mine doesn't bother with flock().

http://io.mine.nu/turbonutter/ view-source.php?file=./header.php (SPACE)

yeah, the warnings are there coz the file for that day was empty - i havent updated the online version to 'die' if the file is empty. if u give me an email address, i'll send u the files - it's quite a lot of code in total (64.5KB of code + 146KB other stuff).

u'll have to work out what variables u need to provide it with. i didnt design it to be user friendly, so when i come to update it, i change stuff until it stops giving me error messages.

Turbo - have you never had the problem where the counter resets to zero, then? One of my sites has suffered this at least three times, and the other one once as well (using the same script).

Nimco - any chance of seeing the source for your php script? A visit to that url just executes it (obviously ...), although it did come up with a number of php warnings.

http://www.great-dunmow.co.uk/gdcounter/print.php

It's still in a beta stage, so feel free to point out bugs...

I just don't bother with locking it. Writing files takes fractions of seconds, and with the load on my sites I doubt simultaneous r/w is going to happen very often, and it;s not as if I care about losing a fewhits anyway.

btw, answers such as "I use MySQL to run my hit counter" are not acceptable. My sites are on Freeola's servers. But then the availability of MySQL is a separate topic ...

In response to some questions / answers.

Ah yes, rude words, the back slash would escape the next character. I forgot about that. I did originally have the filename explicitly in each command, but put it in a variable later on - bad move.

Nope, no good reason for missing out the "t" from "count". Except maybe an old fad of mine to keep variables to 8 character max.

And I've ended up with a ridiculously complicated counter script now, that checks for the presence of a separate "lock" file. If its not there, it means that this user can have control of the counter file, so the script carries on and creates the "lock" file (preventing anyone else from doing so), updates the counter file, and then unlinks (i.e. deletes) the "lock" file.

So tell me, how do you lot out there manage your hit counters?

Here's the blurb from the PHP help manual ...

"mode" may be any of the following:

'r' - Open for reading only; place the file pointer at the beginning of the file.
'r+' - Open for reading and writing; place the file pointer at the beginning of the file.
'w' - Open for writing only; place the file pointer at the beginning of the file and truncate the file to zero length. If the file does not exist, attempt to create it.
'w+' - Open for reading and writing; place the file pointer at the beginning of the file and truncate the file to zero length. If the file does not exist, attempt to create it.
'a' - Open for writing only; place the file pointer at the end of the file. If the file does not exist, attempt to create it.
'a+' - Open for reading and writing; place the file pointer at the end of the file. If the file does not exist, attempt to create it.

So does 'a+' start at the begining of the file???