Updated: sqlite3-22.214.171.124-1 for Cygwin/Cygwin64
Tue Jan 13 21:34:00 GMT 2015
2015-01-12 19:55 GMT+01:00 Warren Young <email@example.com>:
> Example disaster scenario:
> Someone installs Cygwin Fossil, and exposes its critical _FOSSIL_ file to a native Windows program that could modify it. Then all you need is a situation where both programs try to modify it at the same time, and you get DB corruption because they aren’t agreeing on locking semantics.
Another disaster scenario:
Assume someone has tortoisesvn installed, and has a project
checked-out from an SVN server somewhere. The "foo" project
builds a foo.exe cygwin executable, which uses a sqlite repository
located on a shared drive, which is accessed by some
UNIX machines as well. Therefore the "unix" locking is
chosen for interoperability. The user decides to set the
CYGWIN_SQLITE_LOCKING environment variable to
"unix-posix", that's the easiest way.
As soon as tortoisesvn accesses the checked-out working
copy of the "foo" project, it's just a matter of time waiting
for the working copy to get corrupt: Both tortoisesvn and
cygwin svn access the same sqlite database, but they
don't agree on the locking semantics. It's not immediately
clear from this example that svn uses sqlite too, setting
the CYGWIN_SQLITE_LOCKING environment variable
causes this problem.
Remedy: All executables on the same machine should
use the same locking semantics, which can be done
by using the default VFS. Using any other VFS should
> I created it to solve a Cygwin-specific problem.
Yes, and this problem is solved now in the default VFS.
There should be no reason any more to use another than
the default VFS (except in some special situations like
described above). That's what I recommend.
If you know of any situations where the default VFS
mis-behaves in cooperation with other (win32 or cygwin)
programs on the same machine, I'm interested
to hear all about that. But - so far - no-one reported
such a situation to me.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin