Hello --
This is a simple lockfile proposal for gEDA/gaf.
While driving to work the other day, I realized that gEDA/gaf should
implement a lockfile mechanism. Please find my thoughts about that
here, along with a lockfile proposal. I am interested in hearing any
comments -- yea or nay -- from the gEDA developer community.
Lockfiles are necessary because people will (hopefully) use gschem and
gattrib together to manage their schematics. They may indeed run them
simultaneously in two separate windows. Running these two programs
simultaneously means that version skew problems can occur, e.g. when the
user saves his data in gattrib, continues working on it there, but
then edits the data in gschem and saves it out. Apparently, "Clock"
Kulhavy has already done this.
Also, in larger, networked installations, people might want to edit
the same file simultaneously without knowing about each other. This
possibility must be met and managed. This is admittedly a corporate
scenario which is removed from gEDA's current userbase, but why not
architect for it up front?
To solve this problem, I propose a simple lockfile mechanism. The
details are given below. I will code it myself & stick it into the
appropriate libgeda, gschem, and gattrib fcns. First, however, I
thought I'd get some reaction out of the developer community about
what they thought about my scheme.
The lockfiles will be based on the name of each opened .sch file.
Example: schematic_1.sch.lock. There will be one lock file per
opened .sch file. If you are editing a multi-page design, then you
will have multiple lock files. The lockfiles will live in the same
directory as the associated .sch files.
Lockfiles will be simple ASCII text. Inside each lockfile, there will
be the following (for example):
------------------------------------------------------
# This is a gEDA/gaf lockfile signalling that this .sch file
# has been locked for editing. If you are sure that nobody
# is currently editing this file, you may delete this lockfile
# to use gEDA/gaf normally.
#
# user who locked this file
user=sdb
# process number of program creating this lock
pid=345345
# program name which created this lock
program=gattrib
# time when lock was created
timestamp=YYYYMMDD.HHSS
-------------------------------------------------------
GEDA/gaf program behavior when using lockfiles:
1. Upon opening new file, program can optionally tell user that it
is locked by another user, and give him the other user's info
(UID, program used, timestamp of last save). Is this useful to
the user, or just confusing?
2. Upon attempting to save a .sch file, first look for lockfile
on this particular .sch file. Then:
3a. If no lockfile exists, create a lockfile with all program info in
it. Then save out the .sch file normally.
3b. If lockfile exists, read it & check to see if *this* program & pid was
the last program to save this file. Then:
* If so, update lockfile & save normally.
* Otherwise, it means that another user or pid or program is
still using the file. Therefore, throw up this dialog box:
------------------------------------------------------
Warning, this file has been previously locked by user (user) using
the program (other program) who last saved it on YYYYMMDD, at HHSS.
If you save using (this program) now, you may corrupt data for
that user. Click "cancel" to cancel this save operation
and find out why this file is locked.
Otherwise, you may overwrite the saved file by clicking "overwrite".
If you believe that this file should not be locked, you may
simply delete the lockfile /path/to/filename.sch.lock and reattempt
saving your file.
------------------------------------------------------
If the user selects cancel, just exit the file save dialog.
Otherwise, update lockfile, and save.
4. Upon leaving the program, loop through all schematic pages and
check to see if a lockfile exists for this file using this
prog & pid. If so, delete the lockfile. This clears the
.sch.lock file so that others can freely write.
The nice thing about this scheme, IMHO, is that it is transparent &
simple. And if you kill your program abnormally, you can always just
delete the associated lock file & run it again normally.
Comments?
Stuart
