Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Aug 17 09:45:00 GMT 2012

On Aug 16 13:51, Warren Young wrote:
> On 8/16/2012 6:26 AM, Corinna Vinschen wrote:
> >On Aug 16 06:01, Warren Young wrote:
> >>Advisory locking only works when all players cooperate.  We can't
> >>assume that on Windows, unless we set up an insular Cygwin ghetto.
> >
> >So, are you saying that Cygwin should use mandatory file locking?
> Of course not.  That would be a disaster.
> >You are aware that there's no chance at all to implement the UNIX
> >locking API calls correctly this way since Windows locking has nothing
> >in common with UNIX locking except for the word "locking".
> Not even on a per-process basis (cygwin_set_mandatory_locking(1)),
> in conjunction with fcntl(F_SETLK)?  That's how SQLite's
> unixFileLock() function is implemented.
> That is, this proposal would put the DLL in a mode where it called
> LockFileEx() to establish the reader/writer lock byte ranges instead
> of using its private advisory locking scheme.
> Alternately, Cygwin could follow Linux and implement 'mount -o
> mand'. You could get mandatory locking on just your svn checkout
> tree this way, for example.  It would apply to all Cygwin programs,
> not just svn/SQLite, but it shouldn't be any more problematic than
> normal day to day Windows use.  Cygwin programs not run within that
> mount wouldn't be affected.

A "mand" mount option sounds like a really interesting idea, together
with the special group permission settings as described in the Linux
fcntl(2) man page.  Maybe we can even relax that by making the "mand"
option the default setting, so the correct file permissions would be
the only requirement by default.  Ok, this also requires to use a
filesystem with real file permissions, so FAT or "noacl" mounted
filesystems are out of th question, but I can live with that just fine.

The problem with this approach is a non-technical one:  In the next
couple of months I have probably no time to implement it.  It's not
overly tricky to implement it, as far as I can see, but, as usual,
somebody has to do it.  So if anybody would like to take a stab at


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

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

More information about the Cygwin mailing list