Xref: utzoo comp.sources.bugs:988 comp.unix.xenix:2349
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!cory.Berkeley.EDU!dheller
From: dheller@cory.Berkeley.EDU (Dan Heller)
Newsgroups: comp.sources.bugs,comp.unix.xenix
Subject: Re: Mush 6.2 under SCO Xenix
Summary: lockf() and locking() may be swapped in msgs.c
Keywords: locking(), lockf(), (long)0
Message-ID: <3679@pasteur.Berkeley.Edu>
Date: 28 May 88 02:01:21 GMT
References: <706@jclyde.UUCP>
Sender: news@pasteur.Berkeley.Edu
Reply-To: dheller@cory.Berkeley.EDU.UUCP (Dan Heller)
Organization: University of California, Berkeley
Lines: 26

In article <706@jclyde.UUCP> root@jclyde.UUCP (The Super User) writes:
>I recently applied the 6.2 diffs to my mush distribution.  Now when I start
>up (under shell mode) I get a message saying that it can't lock the mail
>file.  When I try to start up under curses mode I get a segmentation violation
>and am asked nicely if I want a core dump.  Anybody else having these troubles?

I don't know this for sure, but the problem _could_ be in the function
lock_file((char *)filename, (int)fd).  If it is, the problem is probably
due to the fact that you don't want to have the routine locking() called.

If you use lockf (which is more likely), then you need to manually edit
your msgs.c file so that the #ifdef's don't have you using locking() and
you should typecast the last argument in lockf to (long).
thus, line 20 of msgs.c:

	if (Access(filename, W_OK) || lockf(fd, F_TLOCK, 0L)) /* system-v */

Followup to this group with success levels.  If it doesn't work, I would
need more information, but those familiar with xenix might be of far more
helpful than I could be on my own.  Obviously, I'm interested in what's
going on, so I'll happily involve myself with any conversation going on.

You also might mail to mush-user@garp.mit.edu since there are quite a few
xenix users there (send requests to join to mush-users-request@garp.mit.edu
NOT the group --thanx).

Dan Heller	<island!argv@sun.com>