I'm playing with a new VFS that targets rollback journal only, using the new atomic batch write interface. When attempting to test it, I ran into a couple issues when building a recent snapshot (FossilOrigin-Name: ea221f3c8e243a5dc4952e510cbe396614a24876bacdc04fb1ebd4127c7ef0d9) with -DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_OMIT_WAL.

It was no trouble to restore the build and tests locally, but I'd rather not maintain these patches. Are the failures an oversight, or are WAL/mmap-less configurations deprecated?

This is what I found with a regular make test. If there's interest in fixing these, I can report back any additional failure for make soaktest.

1. Build failure in os_unix.c's unixFileControl refers to unixFcntlExternalReader unconditionally, but that function isn't defined with -DSQLITE_OMIT_WAL.

2. Tests that assume the WAL code is available:

   • busy2-1 and busy2-2
   • chunksize-2
   • corruptL-14.2
   • delete_db-1.2.0 and delete_db-1.4.0
   • e_wal
   • e_walauto
   • e_walckpt
   • e_walhook
   • exclusive-7.1
   • interrupt2
   • nolock-2.2, nolock-2.12: had to change the expectations around the number of xAccess calls
   • nolock-4
   • pager1-4.4, pager1-35
   • resetdb
   • rowallock
   • symlink-2..4, symlink-2..5: had to change the expectations.
   • symlink-4.2.1, symlink-4.4.2: WAL-only
   • sync2-1.5 through to sync2-1.10.3, and sync2-1.11
   • unixexcl-3
   • wal9

3. It seems like oserror should check for [test_syscall defaultvfs] != "unix" instead of $::tcl_platform(platform)!="unix": builds like mine may override the default VFS but still run on *nix.