[last I looked at Rick Macdonald's tkgnats web page, 3.0.1 was not out
yet.

-kingdon, 14 Dec 1997]

Date: Fri, 12 Dec 1997 12:45:52 -0700 (MST)
From: Rick Macdonald <rickm@vsl.com>
Cc: bug-gnats@prep.ai.mit.edu
Subject: Re: tkgnats and GNATS - lockfiles

On Thu, 11 Dec 1997, Dan Wilder wrote:

Dan - good work! This is indeed a bug, and even worse than you suggested.
:-(

I'm copying this reply to the mailing list.

The new TkGnats version 3.0.0 has a problem such that when running without 
a gnatsd, edited PR's are always left locked after updating.  :-(
(They are unlocked if you cancel the edit.)

I use gnatsd all the time now, so my testing of local disk access wasn't
as complete.

I'll put out a fix in version 3.0.1 in the next day or so.
If you can't wait, here is a replacement file_report proc for
tkeditpr.tcl. This will change if and when GNATS is changed as discussed
below.

proc file_report {} {
    global TkGnats Tkeditpr flds
    if {[real_file_report] == -1} {
        # bell
	headingMsg "Error filing report!"
	headingMsg "" 0
	return -1
    }
    bind . <Destroy> ""
    # GNATS unlocks the PR, so we don't have to.
    # (unless we're doing local disk access with pr-edit).
    if {$TkGnats(GNATS_ACCESS) == "local"} {
        unlock_pr $flds(>Category)/$Tkeditpr(prid)
    }
    exit
}

Dan's mail also pointed out the cause of my error in TkGnats, namely
an inconsistency in the way PR's are locked and unlocked by GNATS.

> I've noticed some problems with dangling lockfiles.  In particular,
> if I change a category using tkeditpr, the old lockfile gets left
> behind, while the pr gets moved to a new directory.

To summarize for everyone:

When a PR is edited and updated, gnatsd (and therefore npr-edit) unlocks
the PR report. pr-edit does not. To compensate, edit-pr does a separate
unlock step but nedit-pr doesn't need to (because it calls npr-edit).

This inconsistency is documented in the gnats/PROBLEMS file:

* gnatsd shouldn't automatically unlock a PR after it's edited---rather,
  the client should do a separate UNLK command.  To do this properly we 
  must:
	* change GNATS_edit to not run unlock_pr
        * clean up gnats::finish-filing to handle it correctly

> which makes it look like the right way to fix it up is call for an 
> unlock from the client side.

Right. When the change recommended in the PROBLEMS file is done, nedit-pr
and TkGnats (and the www interfaces?) will need to call the
appropriate unlock after updating an edited PR.

A related bug lurking around in gnatsd is that it unlocks a PR even when
the edit update fails. I told Brendan about this some time ago and he's
probably got it fixed in his code.

...RickM...