* Fwd: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)
[not found] <CAJtt6BgReBuo=EBfujsLHB+xLW1E_POsdOayDfM_RtyuWRpJbg@mail.gmail.com>
@ 2012-08-31 19:12 ` Terris Linenbach
2012-09-02 10:59 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Terris Linenbach @ 2012-08-31 19:12 UTC (permalink / raw)
To: cygwin
Here is a scenario that involves Cygwin Perl only.
I have a need for multiple Cygwin instances on the same box mainly due
to DLL bases and CPAN modules. I've already read through the endless
threads about both topics so there's no need to mention them. I have
good reasons to do what I'm doing.
Advisory locks don't work across cygwin instances. This is reasonable
but unexpected. That's not such a big deal - use the pidfile pattern
instead, until you realize that kill doesn't work across cygwin
instances either, so you can't check whether the process that owns the
lock is alive. So we are dealing with the possibility of zombie locks,
as well as being extra careful to avoid killing processes. Which, of
course, is impossible in practice.
It would be fantastic if there was eventually a way to get advisory
locks to work across cygwin installations. Mandatory locks would work
too. Or perhaps I should try Perl's own flock implementation.
Any feedback would be gratefully appreciated.
Terris
>
> Greetings, Corinna Vinschen!
>
> > 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.
>
> Sorry byt I can't live with it.
> Setting "noacl" mounts aside from "mand" will force me to choose one or
> another. And it wouldn't be a choice in Cygwin's favor.
> Forced use of POSIX'ised permissions have higher probability of breaking
> existing Windows applications, than using POSIX "suggestive" locks instead of
> appropriate strict locks could harm Cygwin applications.
>
> > 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
> > it...
>
>
> --
> WBR,
> Andrey Repin (anrdae...@freemail.ru) 17.08.2012, <17:01>
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [ANNOUNCEMENT] Updated: sqlite3-3.7.13-1
@ 2012-08-13 17:20 Warren Young
2012-08-16 3:38 ` Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1) Warren Young
0 siblings, 1 reply; 5+ messages in thread
From: Warren Young @ 2012-08-13 17:20 UTC (permalink / raw)
To: cygwin
PACKAGE DESCRIPTION
===================
Homepage: http://sqlite.org/
License : Public Domain (no, really!)
SQLite is a C library providing local database storage with a SQL
interface. Unlike most SQL database systems, SQLite does not accept
connections from remote users. Access to the database requires access
to the file system hosting it; SQLite thus relies on the operating
system's file security for access control. In exchange for this
limitation, you get a smaller, faster database engine that's easy to
embed within a program.
CYGWIN-SPECIFIC CHANGES SINCE LAST RELEASE
==========================================
This is a *test* version which reverts the patch added to 3.7.12.1-1,
which caused problems with Subversion as a side effect, particularly in
systems using non-Cygwin programs with their svn checkout trees.
Through other channels, I've already gotten enough positive reports
about this from those affected that I'm considering making it the
current release. I'm half-expecting SQLite 3.7.14 will come out soon
though; if that happens soon enough, it will become "curr" and 3.7.13
"prev", with all the older versions going away. If 3.7.14 takes longer
to appear than I hope it will, I'll promote 3.7.13-1 to "curr" and drop
the ill-fated 3.7.12.1-1 release so that 3.7.3-1 becomes "prev" again
instead.
In the meantime, this means you need to manually select 3.7.13-1 in
setup.exe if you want to try it.
INSTALL OR UPGRADE NOTES
========================
Manually select it in setup.exe's "Select Packages" screen by clicking
the third column's "Keep" label on all installed "sqlite" packages until
it says "3.7.13-1".
CYGWIN INSTALLATION INFORMATION
===============================
To install this package, click on the "Install Cygwin now" link on the
<http://cygwin.com/> web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:
/usr/share/doc/<package-version>/*
/usr/share/doc/Cygwin/<package-version>.README
If you have questions or comments, please send them to the Cygwin
mailing list.
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
================================
This message has been sent to cygwin-announce list.
If you want to unsubscribe from the mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message. Send
email to the address specified there.
More information on unsubscribing can be found here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at the above URL.
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)
2012-08-13 17:20 [ANNOUNCEMENT] Updated: sqlite3-3.7.13-1 Warren Young
@ 2012-08-16 3:38 ` Warren Young
2012-08-16 9:01 ` Achim Gratz
0 siblings, 1 reply; 5+ messages in thread
From: Warren Young @ 2012-08-16 3:38 UTC (permalink / raw)
To: cygwin
On 8/13/2012 10:12 AM, Warren Young wrote:
>
> This is a *test* version which reverts the patch added to 3.7.12.1-1,
> which caused problems with Subversion as a side effect
I haven't heard peep one from either side about this release on this
list. (For contrast, I've gotten several positive responses in my
answer to the question about this on Stack Overflow[1].)
Silence = happiness, then? :)
I'm asking because it was just announced that SQLite 3.7.14 won't be
released for another 3 weeks[2]. I'm therefore thinking of promoting my
3.7.13-1 package to "curr" posthaste, and having the ill-fated
3.7.12.1-1 package dropped from the mirrors. 3.7.3-1 will remain
available as "prev" for those three weeks. That's assuming I go ahead
and build 3.7.14-1 as the new "curr" package.
[1] http://stackoverflow.com/questions/11007024/
[2] https://www.sqlite.org/draft/releaselog/3_7_14.html
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)
2012-08-16 3:38 ` Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1) Warren Young
@ 2012-08-16 9:01 ` Achim Gratz
2012-08-16 9:03 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Achim Gratz @ 2012-08-16 9:01 UTC (permalink / raw)
To: cygwin
Warren Young <warren <at> etr-usa.com> writes:
> I haven't heard peep one from either side about this release on this
> list. (For contrast, I've gotten several positive responses in my
> answer to the question about this on Stack Overflow[1].)
Sorry, I've been swamped with other stuff...
> Silence = happiness, then? :)
The original bug is back, although it behaves even more wierd than before. The
error now happens _only_ when run as normal user _and_ not under strace or gdb.
$ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> CREATE TEMP TABLE two (id INTEGER NOT NULL, name CHAR(64) NOT NULL );
Error: unable to open database file
sqlite>
Since I can't reproduce the problem in the debugger anymore, it will be
difficult to impossible to find out what's causing this (at least for me). Just
like the problem with TortoiseSVN these are indications IMHO that there's a race
somewhere between calls from the Cygwin DLL and Windows file locking functions.
I can't rule out BLODA either.
So please go ahead and make this version current as it seems to cause less
problems given the widespread use of TortoiseSVN. I'll see to either run the
failing application with elevated privileges or install a local patch to sqlite3.
Thanks for your patience on that matter.
Regards,
Achim.
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)
2012-08-16 9:01 ` Achim Gratz
@ 2012-08-16 9:03 ` Corinna Vinschen
2012-08-16 11:06 ` Promote sqlite 3.7.13-1 from test status? Warren Young
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2012-08-16 9:03 UTC (permalink / raw)
To: cygwin
On Aug 16 07:41, Achim Gratz wrote:
> Warren Young <warren <at> etr-usa.com> writes:
> > I haven't heard peep one from either side about this release on this
> > list. (For contrast, I've gotten several positive responses in my
> > answer to the question about this on Stack Overflow[1].)
>
> Sorry, I've been swamped with other stuff...
>
> > Silence = happiness, then? :)
>
> The original bug is back, although it behaves even more wierd than before. The
> error now happens _only_ when run as normal user _and_ not under strace or gdb.
>
> $ sqlite3
> SQLite version 3.7.13 2012-06-11 02:05:22
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> CREATE TEMP TABLE two (id INTEGER NOT NULL, name CHAR(64) NOT NULL );
> Error: unable to open database file
> sqlite>
>
> Since I can't reproduce the problem in the debugger anymore, it will be
> difficult to impossible to find out what's causing this (at least for me). Just
> like the problem with TortoiseSVN these are indications IMHO that there's a race
> somewhere between calls from the Cygwin DLL and Windows file locking functions.
Cygwin does not use Windows mandatory locking. The locking is entirely
implemented within the Cygwin DLL and is only advisory, as is befitting
for a POSIX envionment. If you try to use the same file with a
non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
you will get into trouble. The mandatory Windows locking will always
win and the Cygwin tool will fail.
Corinna
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status?
2012-08-16 9:03 ` Corinna Vinschen
@ 2012-08-16 11:06 ` Warren Young
2012-08-16 11:39 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Warren Young @ 2012-08-16 11:06 UTC (permalink / raw)
To: cygwin
On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
> On Aug 16 07:41, Achim Gratz wrote:
>> there's a race
>> somewhere between calls from the Cygwin DLL and Windows file locking functions.
>
> Cygwin does not use Windows mandatory locking. The locking is entirely
> implemented within the Cygwin DLL and is only advisory, as is befitting
> for a POSIX envionment.
Interesting. I never knew that. I'd assumed that since Cygwin
occasionally gets tangled up with Windows mandatory locking (e.g. in-use
DLL replacement) that it was playing by those rules all the time.
> If you try to use the same file with a
> non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
> you will get into trouble. The mandatory Windows locking will always
> win and the Cygwin tool will fail.
I think that nails the problem.
SQLite has a lot of Windows and Cygwin specific code in it, and in large
part, it treats Cygwin as "Windows", including use of the Win32 API
LockFile(). (See osLockFile() and winLock*() in sqlite3.c.)
When you force it to build in "Unix mode", all that code gets ifdef'd
out, replaced by an entirely different set of OS-specific I/O wrappers,
such as unixLock().
So, what you did with that requested change, Achim, is prevented Cygwin
svn from winning any fights over ownership of .svn/wc.db.
This could have happened to anything built against Cygwin SQLite, where
there is also another native Windows program trying to access the same
DB file. The only Subversion-specific thing about this problem was how
Subversion was coded to react when it happened. Another program might
not say "disk I/O error," but would somehow fail nevertheless.
Reverting this change put Cygwin SQLite based programs back on an even
footing with native SQLite based programs.
I gotta say, I'm not wild about the way SQLite treats Cygwin as Windows,
bypassing the POSIX APIs so often. Yet, you can see the logic, at least
in the case of file locking. Mandatory file locking is a very good
thing in the case of SQLite.
Anyway, I'm going to update my RFU request to promote 3.7.13-1 to curr.
Thanks all for the responses. It's helped clear things up for me.
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status?
2012-08-16 11:06 ` Promote sqlite 3.7.13-1 from test status? Warren Young
@ 2012-08-16 11:39 ` Corinna Vinschen
2012-08-16 12:48 ` Warren Young
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2012-08-16 11:39 UTC (permalink / raw)
To: cygwin
On Aug 16 04:30, Warren Young wrote:
> On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
> >On Aug 16 07:41, Achim Gratz wrote:
> >>there's a race
> >>somewhere between calls from the Cygwin DLL and Windows file locking functions.
> >
> >Cygwin does not use Windows mandatory locking. The locking is entirely
> >implemented within the Cygwin DLL and is only advisory, as is befitting
> >for a POSIX envionment.
>
> Interesting. I never knew that. I'd assumed that since Cygwin
> occasionally gets tangled up with Windows mandatory locking (e.g.
> in-use DLL replacement) that it was playing by those rules all the
> time.
>
> >If you try to use the same file with a
> >non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
> >you will get into trouble. The mandatory Windows locking will always
> >win and the Cygwin tool will fail.
>
> I think that nails the problem.
>
> SQLite has a lot of Windows and Cygwin specific code in it, and in
> large part, it treats Cygwin as "Windows", including use of the
> Win32 API LockFile(). (See osLockFile() and winLock*() in
> sqlite3.c.)
*shudder*
> When you force it to build in "Unix mode", all that code gets
> ifdef'd out, replaced by an entirely different set of OS-specific
> I/O wrappers, such as unixLock().
That sounds good to me.
> So, what you did with that requested change, Achim, is prevented
> Cygwin svn from winning any fights over ownership of .svn/wc.db.
So what? Don't use native Windows tools in parallel accessing the
same file. Full stop.
> This could have happened to anything built against Cygwin SQLite,
> where there is also another native Windows program trying to access
> the same DB file. The only Subversion-specific thing about this
> problem was how Subversion was coded to react when it happened.
> Another program might not say "disk I/O error," but would somehow
> fail nevertheless.
>
> Reverting this change put Cygwin SQLite based programs back on an
> even footing with native SQLite based programs.
>
> I gotta say, I'm not wild about the way SQLite treats Cygwin as
> Windows, bypassing the POSIX APIs so often. Yet, you can see the
> logic, at least in the case of file locking. Mandatory file locking
> is a very good thing in the case of SQLite.
Why should mandatory locking be better here, while it's quite naturally
using advisory locking in the entire UNIX world?
To put it another way: A native Windows SQLight can do whatever it
wants, I don't care. But a Cygwin SQLight should use POSIX functions
in the first place and, as such, use POSIX advisory file locking
functions and no Windows functions at all, if not absolutely necessary.
And this: If you think it's absolutely necessary to use some Windows
functions, what is it, and why?
Corinna
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status?
2012-08-16 11:39 ` Corinna Vinschen
@ 2012-08-16 12:48 ` Warren Young
2012-08-16 13:32 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Warren Young @ 2012-08-16 12:48 UTC (permalink / raw)
To: cygwin
On 8/16/2012 4:55 AM, Corinna Vinschen wrote:
> On Aug 16 04:30, Warren Young wrote:
>>
>> So, what you did with that requested change, Achim, is prevented
>> Cygwin svn from winning any fights over ownership of .svn/wc.db.
>
> So what? Don't use native Windows tools in parallel accessing the
> same file. Full stop.
I've been maintaining the Cygwin SQLite package for four years now.
This recent wish for SQLite on Cygwin to act more Unix-like is the first
such request I've received, and I don't remember it being an issue with
the previous maintainer, either.
But, shortly after making the change -- because I didn't immediately see
why it would hurt anything -- complaints started pouring in from actual
people who've been doing what you say they shouldn't do.
So what's a package maintainer to do? Go all WJM on them? :)
I don't see why I should break previously working behavior just out of
purity, given that, so far, only one person ever in the entire world has
been bothered enough by that lack of purity to ask me to change how
SQLite is compiled.
> Why should mandatory locking be better here, while it's quite naturally
> using advisory locking in the entire UNIX world?
Because that's what a native Windows build of SQLite does.
(Why? Because https://sqlite.org/faq.html#q5)
Advisory locking only works when all players cooperate. We can't assume
that on Windows, unless we set up an insular Cygwin ghetto.
> If you think it's absolutely necessary to use some Windows
> functions, what is it, and why?
The scenario is this:
Dev Fred likes to use the GUI TortoiseSVN client most of the time.
(Fred is a little strange, but we like him anyway.)
There is no Cygwin port of TortoiseSVN, because it is a deeply
Windows-native program, doing things like adding a shell extension to
Windows Explorer. There is also no Cygwin GUI SVN client we can
recommend people use instead, and even if there were, you can imagine a
lot of people would push back, given the consequent requirement for X11.
On occasion, Fred runs into a situation where the GUI can't do a given
task, or at least can't do it as well as you can from the command line.
What are Fred's options?
Option 1: Download the native Windows Subversion port. Sensible, but it
means you have to use a crippled shell.
Option 2: Install Cygwin and add the svn package, so you have a
reasonable command line environment.
Why should Option 2 result in incorrect behavior, when the correct fix
is known and -- much more important -- already implemented upstream?
Maybe you didn't realize that last, Corinna: Cygwin SQLite is built
pretty much stock OOTB. There's just one minor patch I make, which
replaces a deprecated Cygwin 1.5 DLL call with its v1.7 replacement.
Aside from ifdefs and such, it's about as stock a build as you could
wish. It's not like I'm patching a bunch of Windowsisms into the
upstream source purely for Cygwin's sake.
Upstream's already made the call.
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Promote sqlite 3.7.13-1 from test status?
2012-08-16 12:48 ` Warren Young
@ 2012-08-16 13:32 ` Corinna Vinschen
2012-08-16 20:41 ` Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?) Warren Young
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2012-08-16 13:32 UTC (permalink / raw)
To: cygwin
On Aug 16 06:01, Warren Young wrote:
> On 8/16/2012 4:55 AM, Corinna Vinschen wrote:
> >On Aug 16 04:30, Warren Young wrote:
> >>
> >>So, what you did with that requested change, Achim, is prevented
> >>Cygwin svn from winning any fights over ownership of .svn/wc.db.
> >
> >So what? Don't use native Windows tools in parallel accessing the
> >same file. Full stop.
>
> I've been maintaining the Cygwin SQLite package for four years now.
> This recent wish for SQLite on Cygwin to act more Unix-like is the
> first such request I've received, and I don't remember it being an
> issue with the previous maintainer, either.
Maybe the reason is because subversion didn't use SQLite before?
This change only took place with the update from subversion 1.6 to
1.7.
> But, shortly after making the change -- because I didn't immediately
> see why it would hurt anything -- complaints started pouring in from
> actual people who've been doing what you say they shouldn't do.
>
> So what's a package maintainer to do? Go all WJM on them? :)
>
> I don't see why I should break previously working behavior just out
> of purity, given that, so far, only one person ever in the entire
> world has been bothered enough by that lack of purity to ask me to
> change how SQLite is compiled.
This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.
> >Why should mandatory locking be better here, while it's quite naturally
> >using advisory locking in the entire UNIX world?
>
> Because that's what a native Windows build of SQLite does.
>
> (Why? Because https://sqlite.org/faq.html#q5)
>
> 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?
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".
> >If you think it's absolutely necessary to use some Windows
> >functions, what is it, and why?
>
> The scenario is this:
>
> Dev Fred likes to use the GUI TortoiseSVN client most of the time.
> (Fred is a little strange, but we like him anyway.)
Stop right here. If the compatibility with native WIndows tools is more
important than the compatibility with POSIX and CYgwin POSIX tools with
each other, then why do we bother at all to implement POSIX calls in the
most POSIXy or Linuxy way possible? Every time you don't use the Cygwin
POSIX API in favor of a native Windows call, you're breaking compatibility
with other Cygwin tools.
That's not how it's supposed to be, as far as I'm concerned...
Corinna
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)
2012-08-16 13:32 ` Corinna Vinschen
@ 2012-08-16 20:41 ` Warren Young
2012-08-17 9:45 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Warren Young @ 2012-08-16 20:41 UTC (permalink / raw)
To: cygwin
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.
I'm aware that fcntl(F_SETLK) isn't thread-safe[1] but we're arguing "if
it's good enough for Unix, it's good enough for Cygwin" here, aren't we?
The other objection in reference [1] is that it doesn't work with NFS,
which doesn't matter to us here, I think.
If neither of those proposals will work, I think we'll have no choice
but to continue to try and chase a SQLite specific solution. You can't
fix it on the Windows native side of things. I doubt you can fix it in
Subversion, and even if you could, that's no better than fixing it in
SQLite. Worse, actually, because then you've got a fix that affects
only one program, not all SQLite dependents.
[1] http://0pointer.de/blog/projects/locking.html
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)
2012-08-16 20:41 ` Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?) Warren Young
@ 2012-08-17 9:45 ` Corinna Vinschen
2012-08-17 14:25 ` Andrey Repin
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2012-08-17 9:45 UTC (permalink / raw)
To: cygwin
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
it...
Corinna
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)
2012-08-17 9:45 ` Corinna Vinschen
@ 2012-08-17 14:25 ` Andrey Repin
0 siblings, 0 replies; 5+ messages in thread
From: Andrey Repin @ 2012-08-17 14:25 UTC (permalink / raw)
To: Corinna Vinschen
Greetings, Corinna Vinschen!
> 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.
Sorry byt I can't live with it.
Setting "noacl" mounts aside from "mand" will force me to choose one or
another. And it wouldn't be a choice in Cygwin's favor.
Forced use of POSIX'ised permissions have higher probability of breaking
existing Windows applications, than using POSIX "suggestive" locks instead of
appropriate strict locks could harm Cygwin applications.
> 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
> it...
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.08.2012, <17:01>
Sorry for my terrible english...
--
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-09-02 10:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAJtt6BgReBuo=EBfujsLHB+xLW1E_POsdOayDfM_RtyuWRpJbg@mail.gmail.com>
2012-08-31 19:12 ` Fwd: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?) Terris Linenbach
2012-09-02 10:59 ` Corinna Vinschen
2012-08-13 17:20 [ANNOUNCEMENT] Updated: sqlite3-3.7.13-1 Warren Young
2012-08-16 3:38 ` Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1) Warren Young
2012-08-16 9:01 ` Achim Gratz
2012-08-16 9:03 ` Corinna Vinschen
2012-08-16 11:06 ` Promote sqlite 3.7.13-1 from test status? Warren Young
2012-08-16 11:39 ` Corinna Vinschen
2012-08-16 12:48 ` Warren Young
2012-08-16 13:32 ` Corinna Vinschen
2012-08-16 20:41 ` Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?) Warren Young
2012-08-17 9:45 ` Corinna Vinschen
2012-08-17 14:25 ` Andrey Repin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).