Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 1996 12:52:59 +0200 (MET DST)
From:      grog@lemis.de (Greg Lehey)
To:        dlr@asylum.org (dlr)
Cc:        PLAZAS_CHRISTIAN@mercury.csg.peachnet.edu, questions@FreeBSD.org
Subject:   Re: ELM Config
Message-ID:  <199605291052.MAA20243@allegro.lemis.de>
In-Reply-To: <199605282207.RAA18160@asylum.asylum.org> from "dlr" at May 28, 96 05:07:43 pm

next in thread | previous in thread | raw e-mail | index | archive | help
dlr writes:
>
> Got elm to compile fine but seem to be having a problem with either
> lockfiles or perms. Could someone send me their config file or tell me
> how they have it set up to work. I have 2 bsd boxes that i can't get elm
> to work on (v2.0 and v2.1) and it is something stupid that i am overlooking.

Why did you recompile it?  It's there as standard.

> Elm starts up, then dies trying 6 times saying waiting for mail to arrive.
> Pine works fine but uggh.

This looks like it might be related to an ugly compatibility bug
between 4.3BSD and 4.4BSD.  On earlier systems, struct flock is
defined as

  struct flock {
             short l_type;   /* F_RDLCK, F_WRLCK, or F_UNLCK */
             short l_whence; /* flag to choose starting offset */
             long  l_start;  /* relative offset, in bytes */
             long  l_len;    /* length, in bytes;  0 means lock to EOF */
             pid_t l_pid;    /* returned with F_GETLK */
             };

(this is from SunOS 4.1.3), but in 4.4BSD it is defined as

   struct flock {
             off_t   l_start;        /* starting offset */
             off_t   l_len;          /* len = 0 means until end of file */
             pid_t   l_pid;          /* lock owner */
             short   l_type;         /* lock type: read/write, etc. */
             short   l_whence;       /* type of l_start */
     };

The rationale for this is that some architectures can't place an
8-byte offset on a 4 byte boundary, so there would be a 4 byte gap
between l_whence and l_start in the first example.  By placing the 8
byte values at the beginning, they avoid this hole, but they caused a
number of problems.  In your case, I'd guess that *something* is
defining struct flock wrongly, probably not the system header files.
If you have compiled elm on a Net/2 based system such as FreeBSD 1.x
or BSD/386 1.x, you'll see exactly this problem only on FreeBSD or
BSD/OS 2.x.

Greg




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605291052.MAA20243>