Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Thu, 26 Aug 2004 15:35:03 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: F_ULOCK, F_LOCK, F_TLOCK, F_TEST missing in unistd.h
Message-ID: <20040826133503.GE27978@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4215658170 DOT 20040826103850 AT familiehaase DOT de> <20040826090950 DOT GZ27978 AT cygbert DOT vinschen DOT de> <231908231281 DOT 20040826124602 AT familiehaase DOT de> <20040826113947 DOT GD27978 AT cygbert DOT vinschen DOT de> <412DDF4D DOT 2030603 AT x-ray DOT at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <412DDF4D.2030603@x-ray.at>
User-Agent: Mutt/1.4.2i

On Aug 26 15:02, Reini Urban wrote:
> Corinna Vinschen schrieb:
> >I have already lockf kernel code from FreeBSD in my local sandbox since
> >I began working on that earlier this year at one point.  The most missing
> >resources are spare time and a good idea how to share the lock data
> >between processes in a *sensible* way.  The simple appraoch would use
> >Cygserver to keep track of lock data, but I really don't want to involve
> >Cygserver in file I/O.
> 
> but lockf isn't used that often.
> why not KISS style for the start?

Like this?

  int
  lockf (int fildes, int function, off_t size)
  {
    return 0;
  }

Seriously, the basic idea is not to implement lockf, but to implement
advisory locking.  Windows doesn't support advisory locking, only mandatory
locking.  So, roughly the idea is to use some internal locking structure
and to implement lockf, flock and fcntl-locking on top of that.  All these
implementations are only advisory, so the whole job is to keep the
information ready for all Cygwin processes, and to give them the expected
locking behaviour as a process would get on, say, GNU/Linux, but without
actually locking the files on Win32 level.

Mandatory locking would rather go away entirely.  On Linux, one would have
to enable mandatory locking for the whole file system by using a special
mount flag, plus making sure that the group execute bit isn't set on the
file for which mandatory locking should be used.  AFAICS, that wouldn't
have to be implemented for Cygwin at all.

If somebody is interested to have a stab at implementing that, PTC,
as always.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/