On Jun 30, 2016, at 8:07 PM, Todd C. Olson <[email protected]> wrote: > > Using the fossil OS X binary v1.35 provided at fossil-scm.org in a networked > home directory provided over AFP, I am unable to create a new fossil > repository > % fossil init test01.fossil > SQLITE_IOERR: statement aborts at 1: [BEGIN EXCLUSIVE] disk I/O error
Network file systems often either do file locking incorrectly or skip it entirely. I suspect if you run dtruss on the Fossil binary that you’ll find the error is coming from flock(), fcntl(), lockf() or similar. See: http://www2.sqlite.org/faq.html#q5 > Yet with the sqlite3 provide with OS X I can create and access sqlite > databases with out problem. > That sqlite3 appears to be compiled thusly > % sqlite3 > SQLite version 3.8.10.2 2015-05-20 18:17:19 That proves nothing. You didn’t give a database file name as an argument to sqlite3, and you didn’t try to modify the database. Thus, nothing needs to be written to disk, so there is not even an attempt to lock anything. Try: sqlite3 foo.db 'create table bar (a, b)' > The same behavior occurs with SMB mounting. Proper locking is at least *possible* in principle with SMB, but it’s often broken or disabled on purpose to make file sharing faster. Incidentally, news out of WWDC this year is that AFP won’t be supported for Apple’s new APFS file system. I’m guessing the protocol is tied to ancient Mac OS Classic file semantics, so now is the time to finally give this old protocol the boot. SMB is the official path forward. > I've not yet got NFS setup to test. Locking is entirely optional with NFS. If you aren’t running the separate locking daemon, you won’t get locking at all, and if you are, it may not work anyway. For example, flock() typically doesn’t work with NFS mounts. You have to use POSIX locks to get locking across NFS. This plays into Fossil because SQLite may have multiple ways of doing locks, and there are ways of manipulating its VFS layer to force it to use one method vs another. Thus, either by default or configuration you might be bypassing any NFS locking you *do* have. > Also in a non-networked home directory I can create a new repository without > problem. Since you’re using Fossil, why not store the local clone on a non-network drive and sync with the remote server? Why sync your cloned Fossil repo DB back to the server at all? Realize that your working checkouts don’t have to be on the same filesystem as your local repo clones. > QUESTION 1: Is there a setting that will allow fossil-binary-as-provided to > work on AFP or SMB, command line, environment variable, or something? Possibly, but realize that it may involve digging into the SQLite VFS layer on the local side and may also involve changing settings on the file server. Even then, you’re probably more likely to create a configuration that stops giving errors but instead opens the possibility for data corruption. > QUESTION 2: Is there a way I can compile fossil so that it will run on AFP > or SMB, even if unsafe? No, but I’ve got a leg brace for an S&W N frame revolver here that keeps it pointed right at your foot. Wanna buy it? See section 2 of https://www.sqlite.org/howtocorrupt.html > QUESTION 3: How unsafe is it? It’s far less safe than cloning to a local disk and syncing over the normal Fossil network protocol. > If I am the only user of the system and I am only ever accessing the > repository with one process from one location, is it still unsafe? My guess is “no,” but how are you sure that the use case you outlined will never change? Your question reminds me of amateur electrical work I’ve seen where the justification for all the code violations is that it works as designed. Then it fails as soon as some small thing changes which invalidates the thinking that lead to the brittle design. That’s why the National Electrical Code is written so stringently: because power systems must fail safe in all conceivable use cases. The same goes for DBMSes. > Searching the SQLite build documentation and Fossil build documentation has > not enlightened me That’s because you’re chasing an unsupported configuration. You can’t expect to find documentation describing how to set yourself up for future disaster. > I'm guessing ENABLE_LOCKING_STYLE=1 is important That could indeed help. > how to implement when building fossil? Modify src/main.mk, changing the hardcoded SQLITE_ENABLE_LOCKING_STYLE=0 presently on line 486 to =1. I wonder why that’s not enabled by default? Isn’t that setting essentially harmless? _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
