(I'm cc to the mhonarc list since discussion may be of interest to others)
o A force option. Ie. The ability for mhonarc to update
an archive, even if a lock file exists. QUESTION: Does
the locking work correctly under Windows/MS-DOS systems?
Under DOS locking was not something I could test since it requires
concurrent access by multiple Perl processes, not something one could do
with plain single-tasking DOS. It would show up under networked settings
and now under Win95 and WinNT which have the horesepower to support multiple
copies of Perl running concurrently.
I just tested a tiny abstract of the locking code under Win95 using NTPerl
and a prior DOS Perl.
The prior DOS Perl fails with a file sharing violation (trapped by DOS 7
kernel which issues an error message) when a second process tries to open a
file previously opened by another process but not yet closed. This is the
old DOS default behavior. It is not graceful, but at least it does prevent
a second (and third ...) Perl process from stepping on the files used by a
first process.
That's better than two mhonarc processes writing to the same set of
files. I can live with it.
NTPerl 5 does not work correctly, possibily due to a "feature" in the C
library used in compiling it. After the first Perl process opens a file for
writing, a second Perl process appears to succeed (Perl open() returns true)
in opening the file again for writing. The TRUE from the second open() is
bogus since only output from the first process actually appears in the file.
This behavior would cause the mhonarc locking routine to always succeed on
the first try to open the lockfile. Not cool.
There might be a cure as follows:
1. Implement the force option. Have that delete the lockfile if one exists.
If the deletion succeeds, then proceed.
The force option is only useful if you know there will not be concurrent
mhonarc processes. Ie. The force option would cause mhonarc to do
its job, regardless. A force option can be useful if mhonarc is used
in a cron job. Therefore, a botched execution of mhonarc will not
stop a later execution if the lock file was not removed.
The force option would be very dangerous in automatic archive updating,
like through a .forward file.
The way I plan to implement the force option is as follows: If
a lockfil exists, ignore it, but do not delete it. After update
is made, delete lockfile.
2. In the lockfile test loop, test for the existence of the lockfile instead
of open()ing it for writing. If it does not exist, then open() it
immediately. (Does this separation into two steps make a race more likely?)
Yes. The nice thing about open() is that it is atomic. Doing a test
for existence first, will cause a race condition between the existence
test and the open() call.
Unfortunately flock() does not exist on any DOS platform.
And it does not exist on all Unix platforms. flock() is not standard.
Some Unix systems use lockf(). open() is standard, and works as
expected on all unix systems. open() works on unix systems because of
permissions. The lockfile is create w/no permissions set, so a
subsequent open() on the same file will fail. I'm unsure how NT deals
with file permissions and if there is way to take advantage of them as
on Unix.
If there is no sensible solution for NTPerl, then I'll write a
note in the documentation. NTPerl would be limited to batch updates
to avoid archive corruption.
--ewh
