[pmwiki-users] ugly .flock bug

Patrick R. Michaud pmichaud at pobox.com
Thu May 5 10:16:42 CDT 2005

On Thu, May 05, 2005 at 10:24:00AM -0400, Radu wrote:
> Aw. It happened again.
> I wonder if this happens to others: in betas earlier than 26, if the .flock 
> file gets damaged (no idea how, though), pages would not be read, and 
> pmwiki would return a totally blank html page. The solution was to delete 
> the .flock file in /wiki.d and all was well. In beta32 and now in beta36, 
> if the .flock file gets quirky, pages are seen just fine, but every save 
> reduces the saved file to 0bytes. I was hoping this was fixed in beta36, 
> but it doesn't seem so. (However, this time I had a recent backup so it was 
> not too bad)
> Pm, could you take a look at the code, see where it may differ from reading 
> in saving? To me, it seems handled way differently.

First, I'm going to guess that your "quirky .flock" file isn't the
source of the problem but is rather a symptom of something else,
and that something else is also what is causing pages to fail saving.

The most troubling aspect is that (per your previous message)
you're somehow getting zero-length page files, and with the way
the page save routines are written that *just can't happen*
unless there's something broken in PHP or the OS.  When PmWiki 
saves a page, it doesn't write over the existing page file, but
rather it creates a new temporary page file, checking for errors 
after each write and the final close.  Then, only if the new page 
file has been created successfully does PmWiki rename the temporary
page file to the page file's actual name.

So, if you're getting zero-length page files, that would mean 
that the temporary file is being created as a zero-length file
(this could happen if the account is getting some sort of disk full,
quota reached, or other write error) and PHP and the OS aren't 
returning any write errors back to PmWiki.  Last year I did
run across one reported instance where zero-length files were
being created, but we were never able to track it down precisely.

Now, when you say that PmWiki prior to beta26 would result in 
"totally blank pages" -- do you mean simply that the page 
request times out, and the reader sees nothing?  Or would it
instantly return a blank page?  And by "blank page" do you mean
nothing at all in the browser, or a page with headers and footers
but blank content?

The .flock file itself is used simply to synchronize write access
to the files, it doesn't have any useful contents of its own.
On other systems I've run across a bug in either Apache or the OS
in which a terminated PHP script fails to release its exclusive 
lock on the .flock, thus blocking all subsequent lock requests.
This may be the "quirky .flock" you're talking about, and in
versions prior to beta30 a stuck .flock file would cause all
requests for pages to timeout.  After beta30 read requests no
longer set a lock, but edit requests still require an exclusive
lock before continuing.  But that still doesn't explain how
you're getting zero-length page files in the first place.

> I had to downgrade to beta29 in the meanwhile (thinking that the "Fixed 
> issues with PHP sessions causing deadlock situations." in beta30 introduced 
> this problem; please correct me if I'm wrong). Can't risk to have hours of 
> work disappear like this :(

Beta29 is probably not a good downgrade, as it is quite likely to lead
to a deadlock situation.  I suspect that beta30 didn't introduce
the problem; more likely it simply exposed a problem that was being
masked in previous versions of PmWiki.  Indeed, if in earlier versions
you were having to periodically clear out the "quirky .flock" files
then that's an indication that there's a deeper problem somewhere.


More information about the pmwiki-users mailing list