Discussion:
[ANNOUNCEMENT] Updated: sqlite3-3.7.13-1
(too old to reply)
Warren Young
2012-08-13 16:12:12 UTC
Permalink
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.
Warren Young
2012-08-15 20:50:05 UTC
Permalink
Post by Warren Young
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
Larry Hall (Cygwin)
2012-08-16 03:48:58 UTC
Permalink
Post by Warren Young
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? :)
Well, probably more like no news is good news. They're close cousins
but the former is more optimistic than the latter. ;-)

I think if you've received some positive feedback from other sources,
you should proceed based on that information.
--
Larry

_____________________________________________________________________

A: Yes.
Q: Are you sure?
Post by Warren Young
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Achim Gratz
2012-08-16 07:41:08 UTC
Permalink
Post by Warren Young
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...
Post by Warren Young
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.
Corinna Vinschen
2012-08-16 08:50:16 UTC
Permalink
Post by Achim Gratz
Post by Warren Young
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...
Post by Warren Young
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
Warren Young
2012-08-16 10:30:09 UTC
Permalink
Post by Corinna Vinschen
Post by Achim Gratz
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.
Post by Corinna Vinschen
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.
Corinna Vinschen
2012-08-16 10:55:07 UTC
Permalink
Post by Warren Young
Post by Corinna Vinschen
Post by Achim Gratz
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.
Post by Corinna Vinschen
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*
Post by Warren Young
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.
Post by Warren Young
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.
Post by Warren Young
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
Warren Young
2012-08-16 12:01:36 UTC
Permalink
Post by Corinna Vinschen
Post by Warren Young
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.
Post by Corinna Vinschen
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.
Post by Corinna Vinschen
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.
Corinna Vinschen
2012-08-16 12:26:54 UTC
Permalink
Post by Warren Young
Post by Corinna Vinschen
Post by Warren Young
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.
Post by Warren Young
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.
Post by Warren Young
Post by Corinna Vinschen
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".
Post by Warren Young
Post by Corinna Vinschen
If you think it's absolutely necessary to use some Windows
functions, what is it, and why?
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
Earnie Boyd
2012-08-16 13:32:29 UTC
Permalink
Post by Corinna Vinschen
That's not how it's supposed to be, as far as I'm concerned...
I can see both POV but the Cygwin POV is to DITCW (Do It The Cygwin
Way) which is the de facto correct answer regardless of your own POV.
So the WJM response is in fact a correct response but not one you wish
to here.
--
Earnie
-- https://sites.google.com/site/earnieboyd
Warren Young
2012-08-16 16:01:43 UTC
Permalink
Post by Corinna Vinschen
Post by Warren Young
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?
That's mere happenstance. There's nothing special about Subversion in
this regard. It could have happened with any other pair of SQLite based
programs. The fact that it hasn't until now means the DITCW principle
isn't buying us much in this case.

Understand Corinna, I see your point, and Achim's. Remember that I
accepted Achim's patch and released 3.7.12.1-1 including it. Making
Cygwin SQLite behave in a POSIXy way feels right. But, given that the
new locking behavior causes actual people actual problems, purity alone
isn't looking like such a good reason to keep the new behavior.

If we discard purity as a reason to do this, all we're left with is the
actual problem brought up by one person (Achim) in N years. We can't
solve that problem without causing problems for many others.
Post by Corinna Vinschen
This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.
I agree, in principle, the 3.7.3/13-1 locking behavior is Wrong (tm).

In practice, it breaks *one person's* program, while allowing many
others' programs to work correctly.

It's not like I've refused to even try the pure path. I did try it.
Now that the experiment's been run and I want to revert that change,
returning to the way it's been for *years*, you want me to keep the
problematic change, and thus keep the problems. Why would I?

If you're feeling adamant about this issue, you should take this
package's maintainership away from me, and give it to someone who will
do it the way you want.

Seriously. No bluff, no rancor. I already tried to persuade Achim to
take over maintanership, since it seemed he cared a lot more about the
Cygwin SQLite package than me. He chose not to accept, but maybe he's
still persuadable.
Post by Corinna Vinschen
Post by Warren Young
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?
In a situation like this, you have three choices:

1. Use mandatory locking in the Cygwin program. Ugly, but useful work
gets done.

2. Tell all users of the Cygwin program to stop using the native Windows
program or switch to a Cygwin alternative. This is a bad choice as a
rule, since it tells the world Cygwin doesn't play well with others.
It's worse in this case due to N years of the Cygwin program playing
well with the Windows program. Additionally, there is no GUI Subversion
client in the Cygwin package repo.

3. Tell all users of the native Windows program to stop using the Cygwin
program. Again, it says Cygwin doesn't play well with others.

I suppose there's a fourth choice, where everyone refuses to budge and
you get Palestine. But, that's not going to happen here, because I've
already told you you can take the West Bank if you want it.
Post by Corinna Vinschen
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?
In principle, yes, you're right. But that's the problem with rigid
principles: there are always specific breakdown cases where the
principle causes more harm than good. This is one of those cases.
Brian Wilson
2012-08-16 16:34:44 UTC
Permalink
Post by Warren Young
Post by Corinna Vinschen
Post by Warren Young
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?
That's mere happenstance. There's nothing special about Subversion
in this regard. It could have happened with any other pair of
SQLite based programs. The fact that it hasn't until now means the
DITCW principle isn't buying us much in this case.
Understand Corinna, I see your point, and Achim's. Remember that I
accepted Achim's patch and released 3.7.12.1-1 including it. Making
Cygwin SQLite behave in a POSIXy way feels right. But, given that
the new locking behavior causes actual people actual problems,
purity alone isn't looking like such a good reason to keep the new
behavior.
Post by Warren Young
If we discard purity as a reason to do this, all we're left with is
the actual problem brought up by one person (Achim) in N years. We
can't solve that problem without causing problems for many others.
Post by Corinna Vinschen
This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.
I agree, in principle, the 3.7.3/13-1 locking behavior is Wrong (tm).
Post by Corinna Vinschen
Post by Warren Young
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?
1. Use mandatory locking in the Cygwin program. Ugly, but useful
work gets done.
2. Tell all users of the Cygwin program to stop using the native
Windows program or switch to a Cygwin alternative. This is a bad
choice as a rule, since it tells the world Cygwin doesn't play well
with others. It's worse in this case due to N years of the Cygwin
program playing well with the Windows program. Additionally, there
is no GUI Subversion client in the Cygwin package repo.
Corina is correct, Cygwin is supposed to be a Posix compliant environment so
the SQLite package should follow the Posix standard as the default
behavior. If you want to use Windoze tools, why are you using Cygwin? If
you really must, why not set up Apache under Cygwin and access the Cygwin
Subversion repository through the defined http server interface and the
issue of file locking becomes moot.

Cygwin is not a Windoze/Posix program compatability matching system; it is a
Posix environment on the Windoze platform. There is no intention to have
Windoze only application work directly to Cygwin applications (nor is there
an intention to prevent this either).

As a worst case scenario, why can't the direct SVN access locking behavior
be determined by setting an environment variable. If users want it to work
with Windoze programs (i.e. in a non-posix way), have them set an
environment variable for hard locks; other wise, let the rest of us who want
a Posix experience use the advisory locks. If this solution isn't
acceptable, Cygwin Subversion should use a different DB and drop SQLite.

Sincerely,

Brian S. Wilson
============================================================================
David Rothenberger
2012-08-16 16:45:05 UTC
Permalink
Post by Brian Wilson
Corina is correct, Cygwin is supposed to be a Posix compliant environment so
the SQLite package should follow the Posix standard as the default
behavior. If you want to use Windoze tools, why are you using Cygwin? If
you really must, why not set up Apache under Cygwin and access the Cygwin
Subversion repository through the defined http server interface and the
issue of file locking becomes moot.
The locking issue isn't only related to the repository, it's related to
the workspace itself. The problem people have is when they use
TortoiseSVN and Cygwin svn with the same workspace.
Post by Brian Wilson
If this solution isn't acceptable, Cygwin Subversion should use a
different DB and drop SQLite.
As the current Subversion svn packager, I can say I'm not going to do
that. Subversion upstream only supports SQLite.
Post by Brian Wilson
From a Subversion perspective, I think turning off the TortoiseSVN icon
cache is a reasonable work-around for those that must use both tools.
But as Warren pointed out, Subversion may not be the only case when a
Cygwin tool and a Windows tool want to access the same database at the
same time. I can understand the point that Cygwin SQLite should be
behave POSIX-ly, but if the locking is handled solely within SQLite
itself, does it really matter? Using the same locking that
Windows-native SQLite uses does seem to avoid some interaction issues
without causing any issues for Cygwin programs, so that's a net plus, right?
--
David Rothenberger ---- ***@acm.org

genius, n.:
Person clever enough to be born in the right place at the right
time of the right sex and to follow up this advantage by saying
all the right things to all the right people.
Warren Young
2012-08-16 18:22:20 UTC
Permalink
Post by Brian Wilson
Corina
Corinna.
Post by Brian Wilson
is correct, Cygwin is supposed to be a Posix compliant environment
It's also supposed to interoperate with native Windows programs.
Post by Brian Wilson
If you want to use Windoze tools, why are you using Cygwin?
First, instant 100 point credibility penalty for being puerile.

Second, the whole reason for using Cygwin is so you could have a
Linux/POSIX environment *on Windows.* If you have no need for Windows
programs and want a Cygwin-like environment, wouldn't you be running
Linux, or a BSD, or OS X, or Solaris, or...?

Okay, so you come back saying something about how there should be some
Chinese Wall between the Cygwin and native Windows lands. In that case,
I recommend you install one of the above-named OSes in a VM. It'll be
faster and more featureful.

I'm actually struggling to come up with a reason why you would *ever*
run Cygwin if you didn't ever want it to touch the native Windows side
of things, or vice versa. I guess it uses less RAM and starts up faster
than a VM....
Post by Brian Wilson
you really must, why not set up Apache under Cygwin and access the Cygwin
Subversion repository through the defined http server interface and the
issue of file locking becomes moot.
1. That wouldn't provide all the features some people want. TortoiseSVN
provides a really nice version tree and a spiffy graphical diff
facility, for example.

2. As David said, we're not talking about locks in the repository itself
here. We're talking about a lock on the .svn/wc.db file at the top of
the client-side checkout tree, introduced in svn 1.7.
Post by Brian Wilson
As a worst case scenario, why can't the direct SVN access locking behavior
be determined by setting an environment variable.
Because there's no easy way to do that.

You can't compile SQLite for *both* for Windows and Unix at the same
time. The code simply isn't structured to let you swap I/O subsystems
in and out like that.

I could instead disentangle Windows, Cygwin and Unix in the SQLite code,
and make the Cygwin code switch-hit between locking methods. But keep
in mind, the only reason I maintain the SQLite package is that I know
what it is and how to test it, so I rescued it from being removed from
the Cygwin distro back when its previous maintainer abandoned it. I
simply don't care enough about it to bother with such a big rewrite. It
doesn't help that upstream has ignored multiple requests to integrate
trivial patches for it. I expect they'd be certain to ignore a big one
like this, so I'd then have to keep tracking upstream changes to
reintegrate it each time.

Bottom line, the only options open to you while I'm maintainer are
trivial patches and build system changes.

I suppose I could release *two* versions of SQLite, one for each build
method. I'd still nominate the Windows-aware version as the default.

I'm not sure setup.exe's dependency resolution code can cope with this,
however. I don't recall hearing anything about features like RPM's
"Provides", which lets two different package provide a given facility,
interchangeably. If not, then the nonstandard package would have to be
made available for manual download only, to be unpacked by hand and kept
up to date by hand each time setup.exe overwrites it with a new version.
Blech.
James Johnston
2012-08-16 21:31:23 UTC
Permalink
-----Original Message-----
Sent: Thursday, August 16, 2012 18:22
To: Cygwin-L
Subject: Re: Promote sqlite 3.7.13-1 from test status?
Post by Brian Wilson
is correct, Cygwin is supposed to be a Posix compliant environment
It's also supposed to interoperate with native Windows programs.
Post by Brian Wilson
If you want to use Windoze tools, why are you using Cygwin?
First, instant 100 point credibility penalty for being puerile.
Second, the whole reason for using Cygwin is so you could have a
Linux/POSIX environment *on Windows.* If you have no need for Windows
programs and want a Cygwin-like environment, wouldn't you be running
Linux, or a BSD, or OS X, or Solaris, or...?
Okay, so you come back saying something about how there should be some
Chinese Wall between the Cygwin and native Windows lands. In that case, I
recommend you install one of the above-named OSes in a VM. It'll be
faster
and more featureful.
I'm actually struggling to come up with a reason why you would *ever* run
Cygwin if you didn't ever want it to touch the native Windows side of
things,
or vice versa. I guess it uses less RAM and starts up faster than a
VM....

I was just about to start writing a similar message to this, but you did it
for me very perfectly! What's the point of Cygwin if it can't play nice
with other Windows programs on the system? Go run Linux then! I can point
out several well-known distributions that would work fine. The best part is
they don't require paying license fees to an operating system vendor.

Sometimes I don't understand the antagonism towards interop with native
Windows programs that don't do anything unusual and do things by the
(Windows) book. It seems like it defeats the point of the project if that
goes too far. What's wrong with being pragmatic sometimes?
Yaakov (Cygwin/X)
2012-08-17 02:08:17 UTC
Permalink
Post by James Johnston
I was just about to start writing a similar message to this, but you did it
for me very perfectly! What's the point of Cygwin if it can't play nice
with other Windows programs on the system?
The "point" of Cygwin is clearly stated on our website.
Post by James Johnston
Sometimes I don't understand the antagonism towards interop with native
Windows programs that don't do anything unusual and do things by the
(Windows) book. It seems like it defeats the point of the project if that
goes too far. What's wrong with being pragmatic sometimes?
So you're saying that it is more important for Cygwin's sqlite3 to work
with a Windows program than it is for it to work properly with other
Cygwin libraries and programs? That doesn't sound very pragmatic to me.
Software built for Cygwin should _always_ follow *NIX behaviour.


Yaakov
David Rothenberger
2012-08-17 03:32:55 UTC
Permalink
Post by Yaakov (Cygwin/X)
So you're saying that it is more important for Cygwin's sqlite3 to work
with a Windows program than it is for it to work properly with other
Cygwin libraries and programs? That doesn't sound very pragmatic to me.
Software built for Cygwin should _always_ follow *NIX behaviour.
While I agree with your general point, Yaakov, I don't understand how
the Windows-ish SQLite package does not work properly with other Cygwin
libraries and programs. I suppose if another program tried to get a
POSIXy lock on the SQLite database things would go wrong, but does that
really happen in real life? Can anyone point to an example of the
Windows-ish SQLite package causing a problem in Cygwin, other than
Achim's one report?

If SQLite using Windows locking doesn't break Cygwin programs in real
life, but does break Windows programs that people use in real life (and
not dumb people -- just people that really need/want to use Cygwin and
Windows programs together on the same SQLite database), then is there
really a good pragmatic argument for forcing it to use the POSIX
locking? Maybe there is and I'm not seeing it. Both you and Corrina have
stated there will be problems with other Cygwin programs, but nobody has
mentioned anything specific.

Anyway, that's my $0.02, which is probably not even worth that.
--
David Rothenberger ---- ***@acm.org

Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
Brian Wilson
2012-08-17 19:32:10 UTC
Permalink
Post by Yaakov (Cygwin/X)
Software built for Cygwin should _always_ follow *NIX behaviour.
Yaakov
Amen!
Achim Gratz
2013-02-05 19:51:14 UTC
Permalink
Post by Yaakov (Cygwin/X)
So you're saying that it is more important for Cygwin's sqlite3 to work
with a Windows program than it is for it to work properly with other
Cygwin libraries and programs? That doesn't sound very pragmatic to me.
Software built for Cygwin should _always_ follow *NIX behaviour.
I've had a few minutes to contemplate the SQLite source code. Aside
from the different API used, it appears that the _real_ difference
that's responsible for getting these "disk I/O" errors with the POSIX
code is that for Windows (and Windows only) SQLite implements a
retry-on-failure, complete with exponentially increasing backoff times.

There's two ways to test that theory: one is to set the #DEFINE for the
Windows code so that the retry code is not compiled in (or rendered
ineffective): this should result in just about the same failures that
were seen with the POSIX version. Secondly, to re-implement that
retry-on-failure code in the POSIX section, which should get rid of
these problems altogether.

I'm a bit swamped with real work to do, so I wouldn't mind if someone
could try the first option to confirm that it really delivers the same
sort of interference with TortoiseSVN. If this is indeed the case, it
would instill a greater confidence that the second option would actually
solve the problem in the proper way.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Warren Young
2013-02-11 20:07:27 UTC
Permalink
Post by Achim Gratz
SQLite implements a
retry-on-failure, complete with exponentially increasing backoff times.
Thanks for the investigative reporting. :)

From my perspective, though, I have a new problem, which is scraping
together enough free time to set up the SQLite test suite on a machine
here and set it to grinding, so I can exonerate the recent .15.1 build.
(This in response to David's report that the .15.1 builds cause Cygwin
svn to fail *its* test suite.)

Until someone does that, even with a POSIX exponential backoff patch in
hand, I still can't move forward because I don't know if I'm just
trading one problem for another.

I'm also not entirely sure it's kosher for Cygwin SQLite to have
exponential lock retry backoffs when the Linux build doesn't. And as
I've said before, I haven't yet had any luck getting D. Richard Hipp to
pay attention to even trivial patches to SQLite. If that continues, it
means Cygwin SQLite would be different in this way if I apply the patch
to my package builds.
Achim Gratz
2013-02-11 21:23:37 UTC
Permalink
Hi Warren,
Post by Warren Young
From my perspective, though, I have a new problem, which is scraping
together enough free time to set up the SQLite test suite on a machine
here and set it to grinding, so I can exonerate the recent .15.1 build.
That's the second time I hear you talking about running the test suite
for SQLite… where'd you get that from?
Post by Warren Young
(This in response to David's report that the .15.1 builds cause
Cygwin svn to fail *its* test suite.)
I've seen those particular tests grind to a halt or fail in my testing
as well, with earlier versions of both subversion and sqlite. I'm not
sure what is going on there, but it used to get better with newer
versions of BerkeleyDB IIRC.
Post by Warren Young
Until someone does that, even with a POSIX exponential backoff patch
in hand, I still can't move forward because I don't know if I'm just
trading one problem for another.
As I said, it would be easier to effectively suppress the retry feature
in the Windows-like build to see if the same error happens before making
a foray into adding that feature to (POSIX && CYGWIN).
Post by Warren Young
I'm also not entirely sure it's kosher for Cygwin SQLite to have
exponential lock retry backoffs when the Linux build doesn't.
If Linux had a Win32 daemon that kept locking away files without telling
it would probably need this as well.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
Warren Young
2013-02-11 21:51:25 UTC
Permalink
Post by Achim Gratz
Post by Warren Young
From my perspective, though, I have a new problem, which is scraping
together enough free time to set up the SQLite test suite on a machine
here and set it to grinding, so I can exonerate the recent .15.1 build.
That's the second time I hear you talking about running the test suite
for SQLite… where'd you get that from?
From where? Nowhere. I decided it would be a good idea all by myself.

As I saw it, I released some test builds, they caused a new problem, so
I thought it would be a good idea to see if SQLite's own test suite[*]
gave the same results on both .13 and .15.1. If so, then there is no
regression on Cygwin from that perspective, so that adds a reason not to
consider the BDB failures with Cygwin Subversion a problem.

[*] https://www.sqlite.org/testing.html
Achim Gratz
2013-02-11 22:00:29 UTC
Permalink
Post by Warren Young
https://www.sqlite.org/testing.html
That doesn't seem tell me where to download the testsuite and it's
definitely not in the tarball that Cygwin builds from. Is it in the
"canonical sources" somewhere, perhaps? And how to access those? Sorry
if that's obvious to you…


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Warren Young
2013-02-12 06:26:19 UTC
Permalink
Post by Achim Gratz
Post by Warren Young
https://www.sqlite.org/testing.html
That doesn't seem tell me where to download the testsuite
Quoting that page: "They are contained in the same source tree as the
SQLite core..." That means the Fossil repository, not the "amalgam" the
Cygwin packages are built from.

Steps:

1. Install Fossil. (It's in the Cygwin pkg repo.)

2. Clone the SQLite repo and access it:

$ cd ~/src # or wherever
$ fossil clone http://www.sqlite.org/cgi/src sqlite.repo
$ mkdir sqlite
$ cd sqlite
$ fossil open ../sqlite.repo
$ ls test | wc -l
737

(I have no idea if this is the most efficient way to use Fossil. This
is just what I've figured out playing around in the past 15 minutes.)

3. ....

4. Profit!
Achim Gratz
2013-02-12 17:54:13 UTC
Permalink
Post by Warren Young
Quoting that page: "They are contained in the same source tree as the
SQLite core..." That means the Fossil repository, not the "amalgam"
the Cygwin packages are built from.
Yes, I see that now.
[…]

What I've been missing is that by allowing Javascript on the fossil repo
server you can get a tarball for any release shown. THere's absolutely
no link whatsoever when you have Javascript turned off.
Post by Warren Young
4. Profit!
We'll see. Not immediately, anyway!


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Achim Gratz
2013-03-01 15:11:55 UTC
Permalink
Hi Warren,
Post by Warren Young
4. Profit!
Still not sure about that... If I check out the 3.7.15.2 version and
just configure / make, I'll get a seemingly working sqlite3.exe, but
I can't compile the testfixture. How do you configure the build on
Cygwin and how'd you work around the reams of errors in compiling the
testfixture (if you had to do anything)?

When weeding out the "Cygwin is Windows" stuff from configure.ac, I'll
get past that hurdle and a fairly clean compile of everything (I haven't
checked the whole output, so it may actually be completely clean). There
are a few test errors that are probably harmless, but the testsuite does
indeed produce a few of the dreaded disk I/O errors that seem to have
serious consequences. At least during the "big file" test I found that
while the sqlite from Cygwin _does_ place a lock on that file, it isn't
exclusive -- so you can open the file from a Windows application again
or rename it.

So it seems that indeed the locking stuff is what keeps this from
working correctly. Not sure when I'll find some time to dive into
the sources, but if anybody has some ideas, keep 'em coming.


Regards,
Achim.
Warren Young
2013-03-01 22:52:27 UTC
Permalink
Post by Achim Gratz
how'd you work around the reams of errors in compiling the
testfixture (if you had to do anything)?
I never have run the SQLite tests.

The reason I brought it up is that it could possibly provide a
counterargument against the "svn + bdb breaks" report. If SQLite's own
extensive tests succeed, then we can be pretty sure the problem is BDB.

I've been procrastinating on getting these tests running, which is why
Cygwin SQLite remains at 3.7.13.

At this point, I'm about to give up on it and ship an updated version of
my latetst test packages. That is, with FTS and such features enabled,
the Unix /tmp directory patch, and built in Windows mode.
Post by Achim Gratz
the testsuite does
indeed produce a few of the dreaded disk I/O errors that seem to have
serious consequences.
How?

I mean, shouldn't the test suite be running only pure Cygwin programs,
on files accessed only via cygwin1.dll, with POSIX locking only? If so,
how can you run into locking errors?

The reason this saga started with locking errors is that we were trying
to mix POSIX and Windows native locking. That situation shouldn't
continue within the SQLite test suite.
Achim Gratz
2013-03-02 07:53:18 UTC
Permalink
Post by Warren Young
I never have run the SQLite tests.
I see, thanks for letting me know. That adds another unknown in that
investigation, unfortunately.
Post by Warren Young
At this point, I'm about to give up on it and ship an updated version
of my latetst test packages. That is, with FTS and such features
enabled, the Unix /tmp directory patch, and built in Windows mode.
Yes, I guess that'd make sense.
Post by Warren Young
Post by Achim Gratz
the testsuite does
indeed produce a few of the dreaded disk I/O errors that seem to have
serious consequences.
How?
The test result is different from the expected result, which might
indicate that the wrong data is returned (no overt database corruption
has happened, AFAICS). I haven't yet looked up what those tests are
actually trying to do.
Post by Warren Young
I mean, shouldn't the test suite be running only pure Cygwin programs,
on files accessed only via cygwin1.dll, with POSIX locking only? If
so, how can you run into locking errors?
Since I can't know what to expect for the non-POSIX build (it might be
that these errors are triggered someplace else), I don't know if they
are a consequence of the (at the moment rather crude) changes I made.
Also, "disk I/O error" can unfortunately mean a lot of things, not just
locking, so even that is just an hypothesis at the moment. However,
"Windows programs" are always involved since I can't switch (completely)
off the virus scanner on the build machine.
Post by Warren Young
The reason this saga started with locking errors is that we were
trying to mix POSIX and Windows native locking. That situation
shouldn't continue within the SQLite test suite.
How do you know this wouldn't happen for the "normal Cygwin build? As I
said, while sqlite3 builds in this case, the testsuite doesn't. The
next step will be to try to use the testsuite from the POSIX build and
use it with the sqlite3 for Cygwin.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
David Stacey
2013-02-11 22:49:17 UTC
Permalink
Post by Warren Young
As I saw it, I released some test builds, they caused a new problem,
I'm not sure you introduced a new problem - Subversion's 'bdb' tests
were locking up on both the .13 and .15 builds. Achim thought that this
might be to do with the version of BerkeleyDB being used:
http://cygwin.com/ml/cygwin/2013-01/msg00285.html

Doing a quick Google, other people have questioned the suitability of
Berkeley as a svn back-end:
http://stackoverflow.com/questions/601348/berkeleydb-vs-tokyo-cabinet/601365#601365

So it's entirely possible that this problem is nothing to do with SQLite.

Cheers,

Dave.
Brian Wilson
2012-08-17 19:27:58 UTC
Permalink
Post by James Johnston
Sometimes I don't understand the antagonism towards interop with native
Windows programs that don't do anything unusual and do things by the
(Windows) book. It seems like it defeats the point of the project
if that goes too far. What's wrong with being pragmatic sometimes?
There is nothing wrong with running native windoze programs under Cygwin,
but running Windoze programs is not the purpose of Cygwin/Posix environment;
that is the purpose of Windoze. When the Windoze programs don't work and
play well in the Posix environment; it's to bad they violate Posix's
environment but no reason why Cygwin should abandon its purpose just so a
couple of rude people won't have to do the difficult work of porting a
package. If SQLite has a *inux version available, that should use the
proper Poxix locking anyway. Is there some reason you can't you use this
version as the basis for your port?
JonY
2012-08-16 22:28:43 UTC
Permalink
Post by Warren Young
Post by Brian Wilson
Corina
Corinna.
Post by Brian Wilson
is correct, Cygwin is supposed to be a Posix compliant environment
It's also supposed to interoperate with native Windows programs.
That's fine when it works, but that is not always the case.
Post by Warren Young
Post by Brian Wilson
If you want to use Windoze tools, why are you using Cygwin?
First, instant 100 point credibility penalty for being puerile.
Second, the whole reason for using Cygwin is so you could have a
Linux/POSIX environment *on Windows.* If you have no need for Windows
programs and want a Cygwin-like environment, wouldn't you be running
Linux, or a BSD, or OS X, or Solaris, or...?
So it's Cygwin's fault when a Windows program interferes with it? I
still think Cygwin should prioritize compatibility with Cygwin programs,
anything else is just icing on the cake.
Post by Warren Young
Okay, so you come back saying something about how there should be some
Chinese Wall between the Cygwin and native Windows lands. In that case,
I recommend you install one of the above-named OSes in a VM. It'll be
faster and more featureful.
In fact, yes, especially in places win32 clashes with POSIX
implementation. I could go on and on about how they differ, for example
BLODA, network API, file IO, symlink implementation, you've just seen
one yourself.
Post by Warren Young
I'm actually struggling to come up with a reason why you would *ever*
run Cygwin if you didn't ever want it to touch the native Windows side
of things, or vice versa. I guess it uses less RAM and starts up faster
than a VM....
Sure, a VM isn't always practical or even available, especially when
byzantine IT policies is in place. For instance, I don't want a VM
simply to use a Cygwin irc client.
Warren Young
2012-08-16 19:51:11 UTC
Permalink
Post by Corinna Vinschen
Post by Warren Young
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.
Post by Corinna Vinschen
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
Corinna Vinschen
2012-08-17 09:37:37 UTC
Permalink
Post by Warren Young
Post by Corinna Vinschen
Post by Warren Young
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.
Post by Corinna Vinschen
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
Andrey Repin
2012-08-17 13:05:16 UTC
Permalink
Greetings, Corinna Vinschen!
Post by 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.
Post by Corinna Vinschen
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 (***@freemail.ru) 17.08.2012, <17:01>

Sorry for my terrible english...
Warren Young
2012-08-17 15:04:29 UTC
Permalink
Post by Corinna Vinschen
Post by Warren Young
Post by Corinna Vinschen
You are aware that there's no chance at all to implement the UNIX
locking API calls correctly this way...
Cygwin could follow Linux and implement 'mount -o mand'
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,
I don't see why -o mand is a good default. It isn't the default on
Linux. Besides, wouldn't that dredge up all the hairy problems with
Windows' by-default mandatory locking?

All I'm wishing for here is a way to say "this subtree should use
mandatory locks". The user makes the choice, presumably for good reasons.

I like my per-process Cygwin-specific solution better, though. In that
case, libsqlite would make the decision, because it knows that on
Windows, mandatory locking of SQLite DB files is almost certainly the
right thing. The rare counterexample like Achim's can be handled
through an environment variable or similar; if set, it would cause
libsqlite to pass 0 to my proposed cygwin_set_mandatory_locking() call,
or skip calling it entirely.
Post by Corinna Vinschen
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.
I'm totally fine with limping by with the current solution, where we do
locking the "Wrong (tm)" way in libsqlite for now, with the hope that we
can fix it the Right way later in the Cygwin DLL itself.

Is there old code in the DLL's code repo that does this? I mean, did
the Cygwin DLL use mandatory locking once upon a time, which was
replaced by its current advisory locking scheme, or has it always
provided advisory locking only?
Thrall, Bryan
2012-08-16 14:04:18 UTC
Permalink
Post by Warren Young
Dev Fred likes to use the GUI TortoiseSVN client most of the time.
(Fred is a little strange, but we like him anyway.)
My particular use case is 99% of the time, I use Cygwin SVN, but once in a while TortoiseSVN's revision graph is useful. I think what makes this a bigger problem than "Don't use Windows apps at the same time on the same files as you are using Cygwin on" is just having TortoiseSVN installed triggers the SQLite locking problem, so Fred or I might not have used TortoiseSVN all week but it's still interfering with Cygwin SVN because of its Windows Explorer hooks.

Turning TortoiseSVN's icon overlay caching to "Shell" (or "None") has fixed the problem for me, but I haven't tried SQLite compiled without the Windows file locking. IMHO, if that combination works (icon caching off, SQLite using Cygwin locking), that's the way to go.
Post by Warren Young
What are Fred's options?
Option 1: Download the native Windows Subversion port. Sensible, but it
means you have to use a crippled shell.
Apologies for being pedantic, but TortoiseSVN already provides Windows Subversion command line tools. Your point of the crippled shell stands, however :)
--
Bryan Thrall
Principal Software Engineer
FlightSafety International
***@flights
Andrey Repin
2012-08-17 04:05:36 UTC
Permalink
Greetings, Warren Young!
Post by Warren Young
What are Fred's options?
Use commandline capabilities provided by TortoiseSVN.
Post by Warren Young
Option 1: Download the native Windows Subversion port. Sensible, but it
means you have to use a crippled shell.
There's no such thing as "crippled shell" involved. Crippled knowledge and
inability to use tools at hand - that is.
Even though my favorite interactive shell is Far, and 4NT for batch
interpreter, I often write batch sets in pure CMD. And I can tell you, it's
quite powerful. Not nearly capable and sophisticated as bash, for sure, but
good enough for the job.
Post by Warren Young
Option 2: Install Cygwin and add the svn package, so you have a
reasonable command line environment.
For a task such as running a few commands that is not available from GUI it's
not really required. Or, if you are going to spend time and time again in
console, get something real. I.e., Far manager.
Post by Warren Young
Why should Option 2 result in incorrect behavior, when the correct fix
is known and -- much more important -- already implemented upstream?
The real answer is, if there's native tool available for a single task, and
that only task you'd want it to perform, you're better off with it, than
adding complications of Cygwin to your daily chores.
I'm _not_ advocating against Cygwin here. I'm using it, and _quite_ satisfied
with power and flexibility offered by it.
Still, I'm giving my hard-earned advice. If all you need is one tool for one
task, and it's readily available for native application, you'd better be off
with it.


--
WBR,
Andrey Repin (***@freemail.ru) 17.08.2012, <07:56>

Sorry for my terrible english...
Daniel Colascione
2012-11-17 05:14:53 UTC
Permalink
Post by Achim Gratz
$ 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.
I found the problem: sqlite is trying to create temporary files in the Windows
directory. It's doing that because the internal "getTempname" function is
scanning the Windows environment table for TMP and TEMP, and (because Cygwin
hasn't synchronized the Windows environment with the Cygwin one) doesn't find a
temporary directory, falling back to C:\Windows. You don't see the problem under
the debugger or under strace because both tools synchronize the Windows
environment with the Cygwin one before starting SQLite.

You can work around the problem by synchronizing the environment yourself using
cygwin_internal (CW_SYNC_WINENV) or by explicitly telling SQLite where it should
store its temporary files using 'PRAGMA temp_store_directory="/tmp";'.
Adam Dinwoodie
2012-08-16 08:59:04 UTC
Permalink
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
I misread your original email; I hadn't realized I would need to install a
test version rather than be automatically upgraded (I don't routinely review
what setup.exe installs). And I didn't re-enable TortoiseSVN's icon cache as I
somehow got the impression it would require a new subversion package too. No
idea where that came from. Mea culpa.

I've no objection to you upgrading the package, I just thought I'd point out
the reason for my silence, in case other people who might have spoken up have
made similar errors.
Yaakov (Cygwin/X)
2012-11-20 12:51:37 UTC
Permalink
Post by Warren Young
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.
And in so doing, removed several APIs which were added in 3.7.12.1,
breaking other packages which used them once they were made available.
Compatibility with Windows shouldn't come before backwards compatibility
for Cygwin packages.


Yaakov
Warren Young
2012-11-21 18:42:53 UTC
Permalink
Post by Yaakov (Cygwin/X)
Post by Warren Young
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.
And in so doing, removed several APIs which were added in 3.7.12.1,
breaking other packages which used them once they were made available.
Compatibility with Windows shouldn't come before backwards compatibility
for Cygwin packages.
Okay, that makes a second vote for principle in four months. (The other
being Corinna's.) Add to that the original Achim Gratz vote for "Unix
mode," which carries more weight since it was accompanied by an actual
example of problems.

Over a shorter period, I've received 16 upvotes on my explanation[1] of
the problem and its potential solutions. And, the invitation for
comment I have at the end of that explanation has elicited no comment at
all.

All of this tells me that:

a) There are more people negatively affected by the "Unix mode" build of
Cygwin SQLite than are by building it in "Cygwin mode".

b) There aren't enough people who do care to have SQLite built in Unix
mode to comment knowledgeably about it.

As far as I'm concerned, Cygwin SQLite will remain built in Cygwin mode
until Cygwin has a way to conditionally request mandatory locks, so that
we may have our cake and eat it, too.

If you think I'm wrong, take the package from me, build it your way, and
deal with the backlash you'll receive as a result.



[1] http://stackoverflow.com/questions/11007024/
Achim Gratz
2012-11-21 19:01:33 UTC
Permalink
Post by Warren Young
Post by Yaakov (Cygwin/X)
Post by Warren Young
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.
And in so doing, removed several APIs which were added in 3.7.12.1,
breaking other packages which used them once they were made available.
Compatibility with Windows shouldn't come before backwards compatibility
for Cygwin packages.
Okay, that makes a second vote for principle in four months. (The
other being Corinna's.) Add to that the original Achim Gratz vote for
"Unix mode," which carries more weight since it was accompanied by an
actual example of problems.
FWIW, I think Yaakov is more immediately concerned about the additional
API:

-DSQLITE_ENABLE_COLUMN_METADATA\
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS_PARENTHESIS\
-DSQLITE_ENABLE_FTS4

some of which you've been removing together with the reversion to the
use of the Windows API, maybe even inadvertently.
Post by Warren Young
As far as I'm concerned, Cygwin SQLite will remain built in Cygwin
mode until Cygwin has a way to conditionally request mandatory locks,
so that we may have our cake and eat it, too.
Right. I've not been able to spend much time on it and the windows code
is structured differently enough so it's hard to compare, but if the
database gets locked from a windows application the POSIX API runs into
some sort of timeout that SQLite interprets as a non-recoverable disk
error. Either there should be another (POSIX) API that recognizes the
lock or when the particular error happens it should be checked if the
file is locked — maybe with a windows API, but certainly conditionally
just for Cygwin.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Jon Lambert
2012-11-23 22:13:42 UTC
Permalink
Achim Gratz writes
Post by Achim Gratz
FWIW, I think Yaakov is more immediately concerned about the additional
-DSQLITE_ENABLE_COLUMN_METADATA\
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS_PARENTHESIS\
-DSQLITE_ENABLE_FTS4
Aye. I do use SQLITE_ENABLE_COLUMN_METADATA. I don't believe use of this
API
has anything to do with the Windows vs. Unix locking issues.

I also favor the Cygwin build versus the Unix build. I understand the
argument that
it should be done the Unix way, however the practical matter for myself is
that do share
SQLITE database files with Windows and Cygwin apps.

So I think you're doing the right thing.

--
Jon Lambert
Warren Young
2013-01-08 21:31:23 UTC
Permalink
Post by Achim Gratz
FWIW, I think Yaakov is more immediately concerned about the additional
-DSQLITE_ENABLE_COLUMN_METADATA\
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS_PARENTHESIS\
-DSQLITE_ENABLE_FTS4
I guess I shouldn't have moved this discussion to Cygwin-Apps, since
it's been greeted by crickets for the past 10 days. So to repost:


I've made some SQLite 3.7.15.1-1 packages, and put them up for testing:

http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.7.15.1-1.tar.bz2
http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.7.15.1-1.tar.bz2
http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1-src.tar.bz2
http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1.tar.bz2

These packages enable the requested build options.

In addition, they attempt to work around at least one of the problems
that lead us to try building SQLite in Unix mode on Cygwin in the first
place. Instead of a wholesale Unix mode switch, it patches in just one
focused aspect of this in an attempt to address problems reported both
by Achim Gratz and Daniel Colascione. (Temporary directory selection.)

This required a fairly ugly hack to the SQLite code, so I'm not even
going to consider posting an RFU message for these packages until I get
some positive feedback from those affected.
Achim Gratz
2013-01-08 21:35:41 UTC
Permalink
Post by Warren Young
I guess I shouldn't have moved this discussion to Cygwin-Apps, since
I've downloaded the test packages and been reviewing the patches, but
just being back at work from the holidays I couldn't spend much time on
it yet, especially not setting up a test machine. I'll report back when
I know more.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
David Stacey
2013-01-09 22:27:14 UTC
Permalink
Post by Warren Young
I guess I shouldn't have moved this discussion to Cygwin-Apps, since
it's been greeted by crickets for the past 10 days.
I'm not sure if this is of any use or not, but I did a little testing
with your new sqlite3 package over the Christmas break. I wanted to
rebuild Subversion 1.7.8 and run a few tests. Rebuilding Subversion was
quite straightforward, but I ran into a problem invoking Subversion's
built-in tests with 'cygport check'.

The tests ran for a few hours (say 3 or 4), but eventually appeared to
"lock up" when running the autoprop tests with FS_TYPE=bdb. By "lock up"
I mean that the test appeared to freeze - there was no CPU activity, and
'cygport check' did not return to the command prompt. However, if you
look at the test logs then it reports that the test was 'Interrupted',
although it is not clear by what.

I rebuilt Subversion from clean (again with the test sqlite3 package)
and ran the tests a second time with an absolutely identical result -
the test froze in the middle of the autoprop tests.

The reason that I didn't report this immediately was that I couldn't be
sure that this was necessarily anything to do with your sqlite package.
As a control test, I rebuilt Subversion with the current sqlite3 package
(3.7.13-1) and ran the tests as before. This time the Subversion tests
ran for longer (more than 12 hours) before getting a succession of failures.

At this point I ran out of time for testing, and had too many variables
to make sense of my findings. However, I have attached the test logs
from my test using the new sqlite3 build (the one that froze in the
autoprop tests) in case that is of any use to anyone.

Cheers,

Dave.
Warren Young
2013-01-10 00:08:18 UTC
Permalink
Post by David Stacey
Post by Warren Young
I guess I shouldn't have moved this discussion to Cygwin-Apps, since
it's been greeted by crickets for the past 10 days.
I rebuilt Subversion from clean (again with the test sqlite3 package)
and ran the tests a second time with an absolutely identical result -
the test froze in the middle of the autoprop tests.
Well, I doubt it's the new tmp directory finding code causing this. All
that changes is where the disk space for this comes from, which affects
whether a given user can do certain operations.

It would seem to be either

- something new between 3.7.13 and 3.7.15.1, or
- a side effect of the new features (FTS, etc) that I turned on.

A good test would be to apply the patch from my .15.1-1 packages to .13
and see if the symptom follows the patch.

If the symptom doesn't follow, then I guess I have to bake SQLite using
its own test suite.
David Stacey
2013-01-20 09:22:59 UTC
Permalink
I've done some more testing, but with little success. I ran the
Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch,
and again on sqlite3-3.7.13-1 with the new patch applied. In both cases,
the Subversion tests plodded along nicely and then froze after about 10
hours.

This means one of four things. In order of probability:

- I am not invoking the Subversion tests properly. All I am doing is
building and installing the required version of sqlite3, and then doing
'cygport <cygport-file> prep compile check' on the Subversion sources;
- I have some third-party piece of software (BLODA) that is interfering
with the tests;
- The Subversion tests themselves are susceptible to freezing, and this
problem isn't anything to do with Cygwin or Warren's patch;
- There is some lower-level issue (say in cygwin1.dll) that is affecting
the tests - unlikely as this would affect many other packages also.

So now I have run the Subversion tests on two different versions of
sqlite3, each with and without the patch, and all with the same result
:-( Note that I am starting the tests at different points during the
day, so this isn't a problem caused by some scheduled event running at
the same time each day.

So apologies, but at least I gave it a try. If anyone can spot anything
wrong in the above steps then do let me know and I'll try again.

Cheers,

Dave.
Achim Gratz
2013-01-20 10:45:04 UTC
Permalink
Post by David Stacey
I've done some more testing, but with little success. I ran the
Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch,
and again on sqlite3-3.7.13-1 with the new patch applied. In both
cases, the Subversion tests plodded along nicely and then froze after
about 10 hours.
Is it still freezing in FS_TYPE=bdb? If so, shouldn't you be worried
about BerkeleyDB rather than SQlite? I remember subversion being picky
about the exact version of BerkeleyDB being used and me having to
install a different one than I already had (but that's been a 1.6
version IIRC so things might have progressed). And yes, these tests
take far too long.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
David Stacey
2013-01-20 13:00:57 UTC
Permalink
Post by Achim Gratz
Post by David Stacey
I've done some more testing, but with little success. I ran the
Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch,
and again on sqlite3-3.7.13-1 with the new patch applied. In both
cases, the Subversion tests plodded along nicely and then froze after
about 10 hours.
Is it still freezing in FS_TYPE=bdb? If so, shouldn't you be worried
about BerkeleyDB rather than SQlite? I remember subversion being picky
about the exact version of BerkeleyDB being used and me having to
install a different one than I already had (but that's been a 1.6
version IIRC so things might have progressed). And yes, these tests
take far too long.
Thank you for your reply, Achim. Yes, the freeze happens when
FS_TYPE=bdb. So if we're not concerned with this configuration (for the
purposes of this thread at least), then I can change Subversion's
cygport file so that we only test FS_TYPE=fsfs. This will have the happy
side-effect of halving the amount of time taken to run the tests :-)

If you agree that this sounds sensible then I'll run the tests again
with that change to the cygport file.

Cheers,

Dave.
David Stacey
2013-02-06 22:44:02 UTC
Permalink
Post by David Stacey
Post by Achim Gratz
Post by David Stacey
I've done some more testing, but with little success. I ran the
Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch,
and again on sqlite3-3.7.13-1 with the new patch applied. In both
cases, the Subversion tests plodded along nicely and then froze after
about 10 hours.
Is it still freezing in FS_TYPE=bdb? If so, shouldn't you be worried
about BerkeleyDB rather than SQlite? I remember subversion being picky
about the exact version of BerkeleyDB being used and me having to
install a different one than I already had (but that's been a 1.6
version IIRC so things might have progressed). And yes, these tests
take far too long.
Thank you for your reply, Achim. Yes, the freeze happens when
FS_TYPE=bdb. So if we're not concerned with this configuration (for
the purposes of this thread at least), then I can change Subversion's
cygport file so that we only test FS_TYPE=fsfs. This will have the
happy side-effect of halving the amount of time taken to run the tests
:-)
Apologies for the delay in reporting back, but I've done many hours of
testing on this. I've run four sets of tests, with sqlite3 3.7.13 and
3.7.15, both with and without Warren's patch. The bottom line is that
Subversion appears to function identically in all four cases, and there
was no significant difference in runtime performance (i.e. the time
taken to run the tests).

I can supply more details if you need them, but essentially Subversion
appears to function happily with sqlite3 3.7.13 or 3.7.15, both with or
without the patch.

Cheers,

Dave.
Warren Young
2013-02-11 20:14:33 UTC
Permalink
Post by David Stacey
I've run four sets of tests, with sqlite3 3.7.13 and
3.7.15, both with and without Warren's patch. The bottom line is that
Subversion appears to function identically in all four cases, and there
was no significant difference in runtime performance (i.e. the time
taken to run the tests).
I'm inferring from "four tests" that this result is for the fsfs case
only, and that bdb is still assumed to have a problem.

Since this report of yours on Jan 9, I've been meaning to try and set up
the famous SQLite test suite on a Cygwin box and set it to grinding, to
exonerate the new .15.1 builds. But if we think it now doesn't matter...
Post by David Stacey
I can supply more details if you need them, but essentially Subversion
appears to function happily with sqlite3 3.7.13 or 3.7.15, both with or
without the patch.
.15.2 is out, so do you want me to build a new set of packages for you
to test and potentially GTG?
David Stacey
2013-02-11 22:23:13 UTC
Permalink
Post by Warren Young
Post by David Stacey
I've run four sets of tests, with sqlite3 3.7.13 and
3.7.15, both with and without Warren's patch. The bottom line is that
Subversion appears to function identically in all four cases, and there
was no significant difference in runtime performance (i.e. the time
taken to run the tests).
I'm inferring from "four tests" that this result is for the fsfs case
only, and that bdb is still assumed to have a problem.
Correct. I never got the 'bdb' tests to complete. Personally, I put that
down to a BerkleyDB problem rather than any issue with SQLite - I may be
wrong though.
Post by Warren Young
Since this report of yours on Jan 9, I've been meaning to try and set
up the famous SQLite test suite on a Cygwin box and set it to
grinding, to exonerate the new .15.1 builds. But if we think it now
doesn't matter...
I only tested SQLite through Subversion, so the level of testing I have
given SQLite is only that part that is exercised by Subversion. If you
think that this tests a significant proportion of SQLite then it might
not be worth getting the SQLite test suite to work under Cygwin.
Conversely, if you think Subversion uses only a minority of the SQLite
functionality then it is probably worth continuing your work on the test
suite.

It depends on how much of SQLite you think is exercised by Subversion.
Post by Warren Young
.15.2 is out, so do you want me to build a new set of packages for you
to test and potentially GTG?
Ooo go on then - on the understanding that this is a one-off and I'm not
running hours of tests for each SQLite release ;-) More seriously
though, I can only test SQLite through Subversion, and I have no feel
for how much of SQLite that would be testing. If you're happy with that
then send me a URL.

Dave.
Christopher Faylor
2012-11-21 19:04:27 UTC
Permalink
Post by Warren Young
If you think I'm wrong, take the package from me, build it your way,
and deal with the backlash you'll receive as a result.
FWIW, I don't think you're wrong and I appreciate the due diligence
you've applied to this problem.

cgf
David Stacey
2012-11-21 19:40:38 UTC
Permalink
Post by Warren Young
Post by Yaakov (Cygwin/X)
Post by Warren Young
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.
And in so doing, removed several APIs which were added in 3.7.12.1,
breaking other packages which used them once they were made available.
Compatibility with Windows shouldn't come before backwards compatibility
for Cygwin packages.
Okay, that makes a second vote for principle in four months. (The
other being Corinna's.) Add to that the original Achim Gratz vote for
"Unix mode," which carries more weight since it was accompanied by an
actual example of problems.
Over a shorter period, I've received 16 upvotes on my explanation[1]
of the problem and its potential solutions. And, the invitation for
comment I have at the end of that explanation has elicited no comment
at all.
I'm reluctant to chip into this discussion because there are probably
some strong opinions on both sides. However, my opinions won't count for
anything unless I air them, so...

Whilst I am relatively new to these mailing lists, I have been using
Cygwin for many, many years. I have had to resolve a few conflicts with
other tools over that time - such as disabling my webcam when the driver
clashed with Cygwin's g++, and even now I have to disable my anti-virus
when running setup.exe. These things I tolerate.

However, any conflict with TortoiseSVN is a different matter.

I am a professional software engineer, and Cygwin is one of the tools I
use for my day job. Cygwin is great because it gives me a little Linux
loveliness in a big bad Windows world. But I don't use Cygwin in
isolation - I have many development tools that I use in a Windows
environment, and, yes, one of those is TortoiseSVN.

Cygwin /has/ to function alongside the other development tools I use -
if it can't then I lose interest rapidly. And that means I need Cygwin
svn and TortoiseSVN to play nicely.

Now, I understand the desire for POSIX purity - such aims are laudable
and highly commendable. However, when such ideals stand between me and
getting paid then I take a different view. To put it bluntly, I really
don't care if Cygwin svn uses POSIX locks, Windows locks or anyone
else's locks - as long as it works.

I rather suspect that I am not alone and there are other Cygwin users in
a similar situation.

Apologies for the rant,

Dave.
Christopher Faylor
2012-11-22 16:43:01 UTC
Permalink
Post by David Stacey
I am a professional software engineer, and Cygwin is one of the tools I
use for my day job. Cygwin is great because it gives me a little Linux
loveliness in a big bad Windows world. But I don't use Cygwin in
isolation - I have many development tools that I use in a Windows
environment, and, yes, one of those is TortoiseSVN.
Cygwin /has/ to function alongside the other development tools I use -
if it can't then I lose interest rapidly. And that means I need Cygwin
svn and TortoiseSVN to play nicely.
Now, I understand the desire for POSIX purity - such aims are laudable
and highly commendable. However, when such ideals stand between me and
getting paid then I take a different view. To put it bluntly, I really
don't care if Cygwin svn uses POSIX locks, Windows locks or anyone
else's locks - as long as it works.
To put it bluntly - I don't care. You have the source. If you are a
professional software engineer you can build things yourself exactly
how you like them. We don't have to change the goals of our project
to accommodate you.

Complaining that things don't work perfectly for you when you download
the software for free and have the ability to chart your own course
is not really a compelling argument.
Post by David Stacey
I rather suspect that I am not alone and there are other Cygwin users in
a similar situation.
The old "I rather suspect I am not alone" argument is pointless when
you're responding to a message which enumerates responses from the both
sides of the issue. In fact it is pointless even if those weren't
already in evidence.
Post by David Stacey
Apologies for the rant,
We've already heard these complaints so it is difficult to see the
point.

cgf
Continue reading on narkive:
Loading...