fossil open fails with error when repository is in a VirtualBox shared directory
(1) By anonymous on 2020-07-25 11:56:22 [link] [source]
My setup:
fossil 2.11.1
Host system: Slackware64-14.2
Guest system in VirtualBox-6.1.12: same
a directory containing a fossil repository file on host is set up to be automounted into /mnt/shared of guest via VirtualBox functionality, in read/write mode; while in guest, I have read/write access there, I can create files, I can modify files and save them
but trying to fossil open that repository fails with the following error:
fossil open /mnt/shared/repo.fossil SQLITE_IOERR(1290): os_unix.c:39704: (22) fsync(/mnt/shared/repo.fossil-mjB8716D92A) - Invalid argument SQL: COMMIT Database error: disk I/O error: {COMMIT}
(2) By Warren Young (wyoung) on 2020-07-25 16:52:42 in reply to 1 [link] [source]
That’s a type of network file system, which doesn’t always handle locking semantics correctly. SQLite depends on that to provide its ACID guarantees.
Why not clone the repo into the VM via SSH or HTTP instead?
(3) By Warren Young (wyoung) on 2020-07-25 17:20:44 in reply to 2 [link] [source]
Effectively, Fossil adds a client/server wrapper around SQLite with its attendant benefits.
(4) By anonymous on 2020-07-25 17:41:22 in reply to 2 [link] [source]
Why not clone the repo into the VM via SSH or HTTP instead?
Shared folders required minimal effort to setup for exchanging files between host and guest, and I expected fossil to work as well for consistency.
Now that I'm told this is a VirtualBox shared folders specific problems, I'll look for alternative approaches. I'll try mounting the remote filesystem over sshfs and see if fossil works. If it won't, I'll do stuff over HTTP indeed.
Thank you.
(5) By Warren Young (wyoung) on 2020-07-26 18:32:34 in reply to 4 [source]
Now that I'm told this is a VirtualBox shared folders specific problems
I'm not specifically telling you that, I'm just reporting an oft-repeated observation that network filesystems tend to have more weaknesses when it comes to doing locking and such properly than local filesystems do. It's usually on purpose, to make the network filesystem seem faster at the expense of safety, since for most applications, the extra safety isn't needed.
I'll try mounting the remote filesystem over sshfs
That one I can be more definite about. SSHFS implements the flush and fsync operations, but it does not implement the lock operation. There's a very real possibility that you could corrupt the SQLite DB underlying Fossil by running it over SSHFS.
If you have the ability to use SSHFS, then you can just as well use plain old SSH, over which Fossil is reliable and trustworthy:
$ fossil clone ssh://my-vm/museum/myrepo.fossil ~/museum/myrepo.fossil