I suspected that flock was somehow not behaving the way I expected when the problem was reported. I added the call to sysopen to test whether or not flock was returning TRUE when it should instead be waiting. The non-testing version of the LockFile subroutine doesn't do this.
The idea is that if flock returns TRUE and the temporary file exists, then flock must have been called prevously with LOCK_EX and UnlockFile must not yet have been called. I couldn't think of a better way of testing to see if flock was really working on the web server.
So, if I understand what you are saying, on NFS and/or maybe SMB-mounted disks it's possible that even though the pathname given to the open command is the same, each time, flock may very well treat the file as though it were at a different location and therefore grant the exclusive lock?
When you say NFS or SMB-mounted disks, are you talking about a group of machines acting as resources to a web server?
Thank you for your help.
In reply to Re^2: In a CGI script can flock return TRUE right away even if the file has already been locked?
by rzward
in thread In a CGI script can flock return TRUE right away even if the file has already been locked?
by rzward
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |