Front page | perl.perl5.porters |
Postings from October 2003
Bug(?) in Storable.pm
From:
David P. Mott
Date:
October 31, 2003 09:16
Subject:
Bug(?) in Storable.pm
Message ID:
Pine.WNT.4.40.0310311114350.2776-100000@olorin.net.sep.com
Hi --
I have a problem with Storable.pm on Sun/Solaris (Sun Microsystems Inc.
SunOS 5.8), and I also have a workaround/fix that I'd like to suggest for
the next release of Storable.
The Problem:
Sun/Solaris doesn't have flock. Specifically, in the Perl Config.pm,
the pertenant entries look like this:
'd_fcntl_can_lock' => undef,
'd_flock' => undef,
'd_flockproto' => undef,
'd_lockf' => 'define',
Currently, in Storable.pm, three of these entries are checked to see if
locking *can* be done. That works great.
The problem is in _retrieve(). It turns out that if you're only using
lockf(), then you *MUST* have the file open for writing. Otherwise, you
get an error like "bad file descriptor", or some such.
The Workaround:
Our workaround, just on our Sun/Solaris box, is to change the call to
open() to look like this:
open(FILE, "+<$file) or die (...)
The Real Solution:
But, since you don't always want to open for read+update, we moved the
open (and binmode) call to be just before the flock() call, and we also
added an else block to the if ($use_locking) block which also calls
open(), but only in read mode there.
That works fine for us, but if/when you apply this fix, you should
only open for read+update if all you have is lockf(). I was thinking
that CAN_FLOCK could return a number or an open mode string or some
such, and you could then use it in your call to open(), but that was a
little more time than I cared to spend on it. Otherwise I would have
just submitted a patch. Sorry.
Well, I hope this helps. If you have any questions or need any
clarification, please don't hesitate to ask.
-Dave Mott, SEP
-
Bug(?) in Storable.pm
by David P. Mott