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
Re: [sqlite] oserror-2.1.x fails when run on an BTRFS volume - directories may have any st_size.
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.
On 12/25/19, Stefan Brüns wrote:
> 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.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
--
D. Richard Hipp
d...@sqlite.org
___
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.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
