Re: Re: checking if a file is locked before trying to open it for write?

On 02/17/2015 08:07 PM, Jeffry Killen wrote:

On Feb 17, 2015, at 3:28 PM, Christoph Becker wrote:

Jeffry Killen wrote:

I've been reading my copy of the manual regarding flock() and it appears that a script will have to try to open the file before finding out if it is locked.

Yes, because flock() expects a file handle as first parameter, not a file name.

So, if another script has a lock on the file and the current script does is_writable on the file, will it return false (and trying to open the file will generate a permission denied error ?).

AFAIK is_writable() ignores any locks set via flock().

So what happens when the second user script tries to open the file for write while there is a readonly lock on it? (I'm looking at the sleep() function to simulate the senario and find out what might happen)

This assumes a multi user situation, like two or more admin users are logged into one cms system and are trying to editing the same file at the same time.

Most likely you can't prevent that with flock() only, as the lock is removed as soon as the file handle is closed, what happens at the end of the script, at the latest. So you'll need some kind of "offline" locking strategy. An optimistic approach might be simpler to implement reliably (store a hash of the file contents in the edit form, and check whether the hash of the current file contents has changed when the form is submitted; if so, reject the submission), but might not be appropriate. DokuWiki[1] uses a pessimistic locking strategy, but I don't know how it's implemented. You may have a look at the implementation. [1] <https://www.dokuwiki.org/> -- Christoph M. Becker

Actually, if the user that gets to the file first and his script puts a lock on the file and then removes it, it would be alright, then the second users script can proceed. I know, this raises some other issues like having to recconcile edits to the same file by different users. But the second user could benefit from knowing that his script is being delayed until the lock is removed and a javascript call to location.reload() might be used to resubmit. if flock() is called without the LOCK_NB option, then it will block and wait forever until a lock can be obtained. When flock is called with the LOCK_NB option, then flock will return false immediately if a lock can't be obtained.