SQL failure on checkin
(1) By Doug (doug9forester) on 2022-01-27 00:18:01 [source]
"This is fossil version 2.18 [f96e9dfad3] 2021-11-22 16:12:43 UTC"
Running on Cygwin on Windows 10:
I have a bash script which is introducing versions of a file (and it's 2 generated .exe files) to fossil. When it runs with "bash -x xxx.sh", everything works fine. Sometimes when it just runs as "./xxx.sh", one or more failures occur for "fossil ci". It fails this way about every 5th time I run it.
Here is the script output for the "bash -x xxx.sh" run (works just fine):
+ echo 'fossil ci --tag version=dss.v1.5 ...'
fossil ci --tag version=dss.v1.5 ...
+ fossil ci --tag version=dss.v1.5 --message-file comment.txt --date-override 2018-09-09T11:57:06-07:00
New_Version: 67342cc0a9d6aa8ce8da65011d3b097bdf54c3c2d580c2802e53969eb30578f2
Here is the script output for the "./xxx.sh" run (fails):
fossil ci --tag version=dss.v1.5 ...
SQLITE_READONLY(8): statement aborts at 23: [INSERT INTO rcvfrom(uid, mtime, nonce, ipaddr)VALUES(1, julianday('now'), NULL, NULL)] attempt to write a readonly database
SQL: INSERT INTO rcvfrom(uid, mtime, nonce, ipaddr)VALUES(1, julianday('now'), NULL, NULL)
SQL: SELECT id, 'C:/Users/dougf/documents/autohotkey_fossil/workingbase/' || pathname, mrid, (pathname GLOB '*.ahk' OR pathname GLOB '*.txt' OR pathname GLOB '*.mk' OR
pathname GLOB '*.cmd'), (pathname GLOB '*.exe' OR pathname GLOB '*.gif' OR pathname GLOB '*.ico'), 0 FROM vfile WHERE chnged<>0 AND NOT deleted AND is_selected(id)
Database error: attempt to write a readonly database: {INSERT INTO rcvfrom(uid, mtime, nonce, ipaddr)VALUES(1, julianday('now'), NULL, NULL)}
I am introducing 7 versions of the file to fossil in this script. It failed this way on the 6th version but no others. It's the same repo all the way, so it's obviously not read-only.
Aside: I read all the info about fork today and I wonder if this failure is related. It feels like a timing issue.
(2) By Stephan Beal (stephan) on 2022-01-27 03:43:10 in reply to 1 [link] [source]
Aside: I read all the info about fork today and I wonder if this failure is related. It feels like a timing issue.
It certainly sounds like a timing issue, but not one which has come up before, which suggests that it's a peculiarity of your environment (e.g. virus scanners have been known to interfere with sqlite dbs).
Just out of curiosity: do you get the same if you add:
sleep 1
between each checkin?
(5) By Doug (doug9forester) on 2022-01-27 18:47:26 in reply to 2 [link] [source]
I added a sleep 1 before every fossil ci and open op. I didn't see the failure after that - but I was not seeing the failure very often anyway. I've got about 20 (sub)projects that I am putting into a single repo. If they get in correctly, I'll never using the scripts again. The scripts let me try different arrangements of the branches.
(3) By Dan Shearer (danshearer) on 2022-01-27 11:45:19 in reply to 1 [link] [source]
Doug (doug9forester) on 2022-01-27 00:18:01:
It feels like a timing issue.
There is a way to find out about races in this context. SACLS let you configure Windows filesystem auditing to log all accesses to a given file. If some other process is getting in the way you should be able to see it. The other process might even be your own script, if there is any way of it accidentally calling itself.
Dan Shearer
(4) By Martin Gagnon (mgagnon) on 2022-01-27 11:52:47 in reply to 3 [link] [source]
The other process might even be your own script, if there is any way of it accidentally calling itself.
This, or it could be a "&" at the end of a line that start a command in background where the following command access the same db ?
(6) By Doug (doug9forester) on 2022-01-27 18:59:09 in reply to 4 [link] [source]
There are no "&'s" anywhere - everything is done inline all by itself. The computer is my desktop which no one else can use, much less simultaneously.
I'm going to guess that fossil uses "fork" to manage stuff under the covers. And it's well-documented the issues Cygwin has with fork and the lack of fork in Windows.