On Jan 12, 2015, at 3:28 AM, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> 2015-01-10 5:35 GMT+01:00 Warren Young: > >> My old environment variable mechanism would let you affect the locking >> scheme without changing >> any of the calls to SQLite. Did that get lost with the change to the >> VFS-based scheme? I hope not. > > If you want to restore the old behavior, just add the following lines > somewhere > at the start of your program: What if you are not the author of the program? 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. The fix in this particular case is to switch Cygwin Fossil into mandatory locking mode, but the Cygwin Fossil package maintainer can’t make that the default, since that would make it incompatible with other Cygwin programs. > 1) Why is the environment variable named "CYGWIN_SQLITE_LOCKING"? It's not > cygwin-specific (it would work fine on Linux as well) and changing the > default VFS > does more than only change the locking. I created it to solve a Cygwin-specific problem. If someone with commit permission on SQLite wants to add a feature to SQLite that lets anyone change the VFS via an environment variable on any platform, then of course it should use a different name. I don’t care what it’s called, there just should be a way to change it without rebuilding the program. Sometimes the person who needs to change the VFS isn’t the one who built the program. > I hope that some day > one of those two solutions will be accepted upstream. We will need *both* VFSes forever, because they serve different mutually incompatible use case sets. -- 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
