Re: In a CGI script can flock return TRUE right away even if the file has already been locked?

I believe if the disk is NFS-mounted (or maybe even SMB-mounted), your scheme will fail, because the creation of the file can begin on two separate mounted machines, both apparently succeeding, and both apparently flocking their own view of the world.

If that isn't the case, I'm curious. It seems you're going through a lot more work than a simple flock(). Why did you add so much chicanery?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on Re: In a CGI script can flock return TRUE right away even if the file has already been locked?

Replies are listed 'Best First'.
Re^2: In a CGI script can flock return TRUE right away even if the file has already been locked? by rzward (Monk) on Feb 20, 2006 at 16:48 UTC
Thank you for your comments. 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.	[reply]

Replies are listed 'Best First'.

Re^2: In a CGI script can flock return TRUE right away even if the file has already been locked?
by rzward (Monk) on Feb 20, 2006 at 16:48 UTC

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.

[reply]