develooper Front page | perl.perl5.porters | Postings from October 2003

Bug(?) in

David P. Mott
October 31, 2003 09:16
Bug(?) in
Message ID:

Hi --

I have a problem with 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,
  the pertenant entries look like this:

          'd_fcntl_can_lock' => undef,
          'd_flock' => undef,
          'd_flockproto' => undef,
          'd_lockf' => 'define',

  Currently, in, 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About