Bug(?) in Storable.pm

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