Mail Archives: cygwin/2012/08/16/12:05:01
On 8/16/2012 6:26 AM, Corinna Vinschen wrote:
> On Aug 16 06:01, Warren Young wrote:
>>
>> 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.
> 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.
>> 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.
> 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.
--
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
- Raw text -