With Fossil 2.6, sometimes there's *.fossil-shm and *.fossil-wal files left behind in the directory where the repository databases are stored.
This happens if an unversioned file is accessed through the /uv web interface for the second time (or more). If the web interface to view an unversioned file is accessed for the first time, or if any other page of the web UI is accessed, no such files are present. All web requests seem to complete without signs of error in the web browser (in particular, no red error message on top, also not for non-cached pages other than /uv). There's no suspicious entries in the web server error logs, and no core dump files, or similar. My shared web host is running FreeBSD (64-bit) and Apache, with Fossil 2.6 [9718f3b078] through a CGI script. I haven't been able to reproduce this on Windows, but I have only tested the `fossil ui' mechanism, and not the full web server/CGI setup. I wonder if this could be related to the recently added support for the ETags, Last-Modified, and If-Modified-Since cache control mechanisms, i.e. that there's some "premature shutdown" of the SQLite engine when handling /uv cache hits? I'm aware this is not dangerous, as SQLite will recover any information from the leftover files, but nonetheless I'm reporting it. --Florian (My index-pages are set to unversioned wiki files, and they have hyperlinks to the repository list, so it's a common scenario for me to "leave" a repository through an unversioned index-page, revealing the shm- and wal-files.) _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
