🚀 go-pugleaf

I wrote:
>
> [...]
>
>    /etc/aliases is on the root partition, and is symlink to
>    /usr/local/init/aliases.  /usr/local/init is an NFS partition
>    which I'd like to mount read-only.
>
>The problem is this: when Sendmail (invoked with -bi or as newaliases)
>goes to build the aliases.{dir,pag} databases, it refuses to build
>them if /usr/local/init is mounted read-only (even though the database
>files should be written to /etc, in this instance).
>
>I assume what is going on is that sendmail first stat()'s
>/etc/aliases, and then finds the parent-dir of the stat'ed directory
>and does a writability check on that, rather than simply checking the
>writability of the directory where aliases ostensibly lives (i.e
>/etc).

Turns out I was wrong here.  A browse through alias.c revealed the
following code fragments:

389           * We can't get an exclusive lock on a file that isn't opened for
390           * writing on most systems - sigh!
391           */
392          if ((af = fopen(AliasFile, "r+")) == NULL)
393          {
394                  if (tTd(27, 1))
395                          printf("Can't open %s\n", AliasFile);

[...]

399          }
400  
401  #ifdef DBM
402          /* see if someone else is rebuilding the alias file already */
403          if (flock(fileno(af), LOCK_EX | LOCK_NB) < 0 &&
404              (errno == EWOULDBLOCK || errno == EAGAIN))

Now on SunOS, the man page for flock() says this:

> BUGS
>      Locks obtained through the flock() mechanism are known  only
>      within the system on which they were placed.  Thus, multiple
>      clients may successfully acquire exclusive locks on the same
>      remote  file.   If  this behavior is not explicitly desired,
>      the fcntl(2V)  or  lockf(3)  system  calls  should  be  used
>      instead;  these make use of the services of the network lock
>      manager (see lockd(8C)).

Is there some reason the aliases file couldn't be locked using fcntl()
or lockf()? 

-Dan