Re: [sqlite] Is it possible to dump a sqlite db that has an associated -wal file?
On Sonntag, 16. Februar 2020 21:50:18 CET Simon Slavin wrote: > On 16 Feb 2020, at 8:44pm, Stefan Brüns wrote: > > On Sonntag, 16. Februar 2020 21:26:00 CET Simon Slavin wrote: > >>> One use case I am aware of (although this targets places.sqlite, not > >>> cookies.sqlite) is reading the history, bookmarks and tags.>> > >> These things can be done using the bookmarks API, WebExtensions API, and > >> other methods. Reading the SQLite database is actually more difficult.> > > AFAIK this only works while FF is running ... > > That is the problem that started this thread: that the database file could > not be opened while FF was running. The database being inaccessible while FF is running does not equate to FF is always running. Both cases (with and without FF running) have to be covered. And having to write two different access methods (direct access and through bookmarks API) is obviously the worst of all variants. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Is it possible to dump a sqlite db that has an associated -wal file?
On Sonntag, 16. Februar 2020 21:26:00 CET Simon Slavin wrote: > > One use case I am aware of (although this targets places.sqlite, not > > cookies.sqlite) is reading the history, bookmarks and tags. > These things can be done using the bookmarks API, WebExtensions API, and > other methods. Reading the SQLite database is actually more difficult. AFAIK this only works while FF is running ... Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Is it possible to dump a sqlite db that has an associated -wal file?
On Sonntag, 16. Februar 2020 18:36:15 CET Simon Slavin wrote: > On 16 Feb 2020, at 5:15pm, Peng Yu wrote: > > Why the database can not be read by another sqlite3 session when the > > corresponding -wal file exists? Thanks. > > This is done on purpose by the developers of Firefox to prevent a security > vulnerability which I will not describe in public. Will this stop anyone from just copying the DB without the -wal file? Afterwards, the DB can be read, as there is no longer any associated log. > One of the Mozilla developers involved in the decision reads this list. If > you have a good reason why you want to open the SQLite database while > Firefox is running, you could post it here. You might be able to persuade > them to reconsider the decision. One use case I am aware of (although this targets places.sqlite, not cookies.sqlite) is reading the history, bookmarks and tags. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-3.31.0 segfaults on fuzzcheck on s390x architectures
On Dienstag, 28. Januar 2020 18:26:05 CET Brüns, Stefan wrote: > > On armv7l, there is another failure in the fuzztests, with and without the > patch: > sessionfuzz-data1.db: sessionfuzz: ./sqlite3.c:57249: pager_open_journal: > Assertion `rc!=SQLITE_OK || isOpen(pPager->jfd)' failed. I had previously overlooked this, but the fuzz check also fails on ppc32be, but passes on i586 (and all tried 64bit archs). Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite-3.31.0 segfaults on fuzzcheck on s390x architectures
On Mittwoch, 29. Januar 2020 13:40:44 CET Richard Hipp wrote: > Please retry using this check-in: > https://www.sqlite.org/src/info/b20503aaf5b6595a The failings test now pass on all architectures: - ix86/x86_64 - armv7hl, aarch64 - ppc32be, ppc64be, ppc64le - s390x Kind regards, Stefan > On 1/28/20, Brüns, Stefan wrote: > > On Dienstag, 28. Januar 2020 18:26:05 CET Brüns, Stefan wrote: > >> On Dienstag, 28. Januar 2020 16:16:01 CET Richard Hipp wrote: > >> > On 1/27/20, Ondrej Dubaj wrote: > >> > > Hi, > >> > > > >> > > I came across a problem during mate test, where fuzzcheck ends with > >> > > segfault. > >> > > The problem appears to be only on [s390x]. Other architectures are > >> > > working fine. > >> > > >> > Fixed by check-in https://www.sqlite.org/src/info/04885763c4cd00cb > >> > > >> > Thanks for the temporary SSH login! > >> > >> We were seeing the problem also on other ppc64BE: > >> > >> ppc64 (big endian): > >> fuzzdata1.db: 0% 10% 20% 30% 40% 50% 60% 70%./fuzzcheck > >> /home/abuild/rpmbuild/ BUILD/sqlite-src-3310100/test/fuzzdata1.db > >> (sqlid=7726,dbid=1): segfault > >> > >> The issue is cured with the fix, but we still see 3 failing tests with > >> fts4/ > >> fts5: > >> > >> ! fts5matchinfo-15.1 expected: [X'0200'] > >> ! fts5matchinfo-15.1 got: [X'0002'] > >> ! fts5matchinfo-15.2 expected: [X'0200'] > >> ! fts5matchinfo-15.2 got: [X'0002'] > >> ! fts4aa-6.10 expected: > >> [X'02000E000E0001000100010001 > >> 00' ] ! fts4aa-6.10 got: > >> [X'0002000E000E00010001000100 > >> 01' ] [...] > > > > This is 3.31.1, btw. > > -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Truncation/rounding error in strftime(x, 'unixepoch')
Hi, some time ago there was an error reported when running the testsuite on ix86, in the date.test/date-2.2c-*. The error happens as a string like 1237962480.003 gets parsed and rounded to 1237962480.002999... and is later truncated to 1237962480.002. The rounding error happend in date.c:parseModifier(...): p->iJD = (sqlite3_int64)r; i.e. the double r is truncated by casting it to int. Doing the following change fixes the error on ix86, and lets the testsuites pass on i586, x86_64, aarch64, ppc64le, ... - p->iJD = (sqlite3_int64)r; + p->iJD = (sqlite3_int64)(r + 0.5); Also compare with date.c:setRawDateNumber(...), where rounding is already applied: p->iJD = (sqlite3_int64)(r*8640.0 + 0.5); Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] oserror-2.1.x fails when run on an BTRFS volume - directories may have any st_size.
On Donnerstag, 26. Dezember 2019 02:01:36 CET Richard Hipp wrote: > Tnx for the report. Should be fixed as of > https://sqlite.org/src/info/c8c6dd0e6582ec91 > > Please do us the favor of trying this out on both Btrfs and XFS and > making sure it works correctly on both filesystems. Tnx. Thanks for the quick fix. I did a quick test on BTRFS and it works, XFS is pending. The fix requires a small amendment though, there are other types than directories which have an st_size of 0, sockets, pipes, ... The size check probably should only be done for regular files - symlinks can never have a size of 0, and all others are implementation defined. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] oserror-2.1.x fails when run on an BTRFS volume - directories may have any st_size.
The oserror-2.1.1 test fails, as a exisiting test.db-wal is silently ignored.
Running this small example on e.g. XFS or tmpfs yields the following:
$> mkdir test.db-wal
$> strace -efile sqlite3 test.db
...
sqlite> .databases
openat(AT_FDCWD, "test.db", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis
nicht gefunden)
lstat("test.db", 0x7ffc38d3b8c0)= -1 ENOENT (Datei oder Verzeichnis
nicht gefunden)
getcwd("/home/stefan", 511) = 13
openat(AT_FDCWD, "/home/stefan/test.db", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 3
stat("/home/stefan/test.db", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("/home/stefan/test.db-journal", 0x7ffc38d3a730) = -1 ENOENT (Datei oder
Verzeichnis nicht gefunden)
stat("/home/stefan/test.db-wal", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
unlink("/home/stefan/test.db-wal") = -1 EISDIR (Ist ein Verzeichnis)
Error: disk I/O error
Doing the same on an btrfs volume:
$> mkdir test.db-wal
$> strace -efile sqlite3 test.db
...
sqlite> .databases
stat("/var/tmp/t/test.db-journal", 0x7fff01578140) = -1 ENOENT (Datei oder
Verzeichnis nicht gefunden)
stat("/var/tmp/t/test.db-wal", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/var/tmp/t/test.db-journal", 0x7fff015790e0) = -1 ENOENT (Datei oder
Verzeichnis nicht gefunden)
stat("/var/tmp/t/test.db-wal", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
main: /var/tmp/t/test.db
sqlite>
The culprit is the st_size check in os_unix.c/unixAccess:
...
if( flags==SQLITE_ACCESS_EXISTS ){
struct stat buf;
*pResOut = (0==osStat(zPath, &buf) && buf.st_size>0);
}else{
...
Changing it to ".. && ((buf.st_size>0) || (buf.st_mode & S_IFMT ==
S_IFDIR)));" fixes the problem.
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Misleading comment in various test/fts*.test files
In the various test files, there (in most cases) is a misleading comment.
In i.e. fts3expr.test, the comment is inverted, in fts3fault2 it is correct:
test/fts3expr.test:# If SQLITE_ENABLE_FTS3 is defined, omit this file.
test/fts3expr.test-ifcapable !fts3 {
--
test/fts3fault2.test:# If SQLITE_ENABLE_FTS3 is not defined, omit this file.
test/fts3fault2.test-ifcapable !fts3 { finish_test ; return }
Kind regards, Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] fts3corrupt4-33.0 depends on SQLITE_ENABLE_ICU
The test added in https://www.sqlite.org/src/info/e01fdbf9f700e1bd
requires icu to run successfully. Otherwise it errors out with:
! fts3corrupt4-33.0 expected: [1 {database disk image is malformed}]
! fts3corrupt4-33.0 got: [1 {unknown tokenizer: icu}]
Kind regards, Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
signature.asc
Description: This is a digitally signed message part.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
