This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: F_ULOCK, F_LOCK, F_TLOCK, F_TEST missing in unistd.h
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 28 Aug 2004 11:14:42 +0200
- Subject: Re: F_ULOCK, F_LOCK, F_TLOCK, F_TEST missing in unistd.h
- References: <20040827101109.GK27978@cygbert.vinschen.de> <200408280228.i7S2SIs3014737@mx3.redhat.com>
- Reply-to: cygwin at cygwin dot com
On Aug 27 21:27, Gary R. Van Sickle wrote:
> > On Aug 26 22:48, Gary R. Van Sickle wrote:
> > > Well, I just did my 2 minute due diligence and looked up the
> > > difference between advisory and mandatory file locking. Did I read
> > > right? Does advisory locking actually in no way prevent
> > write access to the "locked"
> > > file unless all the interested processes also explicitly
> > use lockf() etc?
> >
> > Yes.
> >
>
> Wow. Is this acually a useful thing, or just an unseemly holdover from the
> bad-old-days?
Yes, this is a useful thing. Also POSIX does only define advisory locking.
See "mandatory.txt" in the Linux docs for more information.
> Hmmm. Well, is there some reason you couldn't just use LockFile{Ex} et al?
> Any apps that are expecting to simultaneously write to the same file without
> "real" locking are busted anyway, aren't they?
LockFile/LockFileEx are mandatory locking, plus they are far from having
POSIX semantics. See MSDN, especially the description of UnlockFileEx.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.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/