Michael, I hope you don't mind if I carbon-copy my reply to the mailing
list. I might as well share my brief history of Win32-locking versions
Michael Bell <guineverehelp@...> writes:
> dan - have you looked at http://www.openhandhome.com/howtosa.html?
> I'd say the outstanding issues are
> 1. Spamc/Spamd compatibility
I haven't really looked at that. I've been focused on the general
library code and SAproxy (formerly known as pop3proxy). It would be
fine by me to get some patches into SA for this, though.
I'd like to get away from requiring various Win32 users/developers to
make their own changes to the core code to get it working.
> 2. NFS file locking doesn't work reliably, hence in auto-white-lists
> and Bayes, I've tended to advise people to rewrite to use FLOCK (uggh)
I looked at your flock() implementation and originally used my own
implementation own that did everything correctly (retries and such).
The main problem is that flock() isn't supported on all Win32 platforms.
In particular, we know it doesn't work on Win98 using ActiveState Perl
I also don't know if it actually works over NFS and CIFS, but it's
basically a moot point since flock() doesn't work on Win98.
For the moment, I've settled on using a sysopen-based locking routine.
See this bug for the current proposed version:
I'll attach the complete code to the bottom of this message. This
implementation has nice properties:
- it doesn't entirely rely on stat() working to delete stale locks (it
tries the -M operator at the beginning, so stale locks can be broken
even when stat() doesn't work right; I don't use -M in the loop,
though, since -M is modification age since the script started, not
- sleep doesn't happen right before an failure exit (it was surprising
how long the original Unix code had this problem)
- there is a warning for unlink() not working (can indicate a failure
of the locking code)
That code is replacing the current Win32-code in SA 2.50-cvs that uses
mkdir-based locking which I decided to replace it since it didn't really
have any advantages over the sysopen-based routine (except *maybe*
working over NFS, but who knows if mkdir is atomic on Windows). Using
sysopen() has the problem of not probably supporting NFS, but I want to
reliably work on one system before I worry about network filesystems.
I've also looked into using Win32::Mutex, but I'm hesitant to use it
since it appears that the mutex can't be broken (when the locking
process doesn't die, although when it does die, the lock seems to be
automatically dropped). This solution is also specific to one computer
as far as I know.
> 3. ALARM doesn't work, which mucks up a lot of 3rd party stuff like
I haven't even tried Razor yet, but it was on my list of things to do in
the near future (like next week). I would like to get it working soon.
> 4. I've gotten a preliminary report from one user that Net::DNS
> doesn't work in ActiveState Perl 5.8. Not sure if that's true
It's true. Net::DNS doesn't even ship with ActiveState Perl 5.8. I
installed my own version of Net::DNS 0.33, but have had some problems
that I'm still looking into.