As I commented to you privately, virtually everyone who I have seen try to use file locking has messed it up very seriously. Normally this involves both technical mistakes (explicitly unlocking rather than relying on close to do it for you - a mistake whose severity is lessened in Perl because Perl does a flush for you) and conceptual ones (locking operations rather than tasks).

Now if you really want to proceed, want it portable, and are willing to aggressively back up your data for the inevitable failures, then the right way to go is to rename the file to a private name, check that you got the file (if not then wait and try again in a bit - you can do fine-grained timeouts with select), manipulate it, and then rename it back.

This relies on the fact that rename is an atomic operation on virtually every platform and filesystem (so long as you are not moving the file across filesystem boundaries). It opens you to the fact that Some Day your CGI script will die while the file is renamed and you will lose all of your data.

You did have backups?

UPDATE
Corion asked me whether rename is atomic on NFS. I thought it happened atomically even there, but I don't have a reference handy. Can anyone confirm or deny?

Note that I do not mean that from issuance to action is atomic - that is impossible due to network latency. What I mean is that if 2 processes (possibly on different boxes) both try to rename at the same time, one will succeed, one will fail, and the file will arrive at a new name intact.