Yes, there is a race condition where multiple clients can reset the same counter in rapid succession and both succeed. However, this race doesn't affect the requested purpose, that is, people will not be allowed to reset a count by doing a refresh/reload of a page. That is mostly why I didn't mention the race condition originally.

A more important flaw (to my eye), is that the solution doesn't distinguish between refusing my reset request because someone else beat me to it or because I resent a stale POST.

The "right" way to remove the race condition is to lock the timestamp file across the test and set. However, that wouldn't fix the bigger flaw. My subconscious has been wondering if there was a (fairly) simple trick for solving both problems (like append the process ID/thread ID/client address&port to the time stamp file, check if you were first, etc.). This type of problem often looks simple but usually isn't. Anyway, I never came up with one.

So lock the file, check the file's last modified time, and then either rewrite it with a unique ID that you also include hidden in each form or read the ID to determine which error to report, then unlock the file.