On 7/17/2013 17:15, fger...@gmx.de wrote:
Von: "Warren Young" <war...@etr-usa.com>
try setting the new CYGWIN_SQLITE_LOCKING environment
variable to "posix".
Why isn't it the default?
Because there are more native Windows programs based on SQLite than
there are Cygwin programs based on SQLite.
Since we cannot interoperate with both sets of programs at the same
time, we chose to interoperate with the larger set by default.
I copied the mozilla places.sqlite bookmarks file to a backup directory
This at least gives me a way to reproduce it.
For anyone else who cares:
$ cp ~/AppData/Roaming/Mozilla/Firefox/Profiles/*/places.sqlite /tmp
(~/AppData is a symlink to the obvious location on my machine.)
$ sqlite3 /tmp/places.sqlite .schema
The query string can be anything that causes it to access the DB file.
So, it can't just be ".quit", for example.
I've done some strace diffing, and the problem seems to happen outside
the Cygwin DLL, immediately after the new locking code is called:
read: 32768 = read(3, 0x80054620, 32768)
flock: 0 = flock(3, 8)
fhandler_pty_slave::write: pty0, write(0x40A502, 7)
fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
fhandler_pty_slave::write: (654): pty output_mutex: acquired
fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
write: 7 = write(2, 0x40A502, 7)
fhandler_pty_slave::write: pty0, write(0x80053FF0, 28)
fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
fhandler_pty_slave::write: (654): pty output_mutex: acquired
fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
write: 28 = write(2, 0x80053FF0, 28)
fhandler_pty_slave::write: pty0, write(0x40A50B, 1)
fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms
fhandler_pty_slave::write: (654): pty output_mutex: acquired
fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released
write: 1 = write(2, 0x40A50B, 1)
Distilled, what this says is that it successfully read()s from the DB
file it has open (fd=3), then it successfully flock()s it, and then for
reasons I don't understand, does 3 write()s to stderr.
The mystery is what happens between lines 2 and 3, and for that I don't
see anything for it but to dive back into the SQLite code.
Does the sqlite file contain a locking flag inside?
Nothing so simple. Locking is handled at the OS and/or Cygwin DLL
level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now
relying on new features in the Cygwin DLL to do Windows-style locking by
default.
Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for
this, going straight to the Win32 API, thereby preventing the DLL from
interposing itself for the "posix" case.
With the old version
I never had a problem to access the files.
Yes, well, other people did have trouble with the old version, which is
why we tried giving locking responsibility to the Cygwin DLL.
--
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
