For now I've backed out the commit in question, along with a few things downstream of it.  Here's the backout: <https://fossil-scm.org/home/info/0a7526522085631f>.

Now fixed, thanks to <https://fossil-scm.org/home/info/857777f117eb0d5a>.

I am glad, one of my personal projects really benefits of the multi-remotes autosyncing all at once.

Turns out there's another problem now, introduced either by the original change [f11c863d91c251d0](https://fossil-scm.org/home/info/f11c863d91c251d0) or by the correction [857777f117eb0d5a](https://fossil-scm.org/home/info/857777f117eb0d5a).  I used a bisect to confirm this is when things went wrong.

Cloning from one filesystem file to another results in the following:

>
    $ fossil clone a.fossil b.fossil
    SQLITE_ERROR(1): no such table: global_config in "DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';"
    Database error: no such table: global_config: {DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';}

For now, I brought back the [temporary-fix](https://fossil-scm.org/home/timeline?r=temporary-fix) to include everything but the multi-remote capability.

To better reflect its purpose, I renamed the branch from temporary-fix to [multi-remote-fix](https://fossil-scm.org/home/timeline?r=multi-remote-fix).

I compared the output of `fossil -sqltrace` between [trunk](http://fossil-scm.org/home/info/dcc90ab5e1b49b1b) and [multi-remote-fix](http://fossil-scm.org/home/info/719dcd29cd8a99d5).  This revealed the problem to be use of [db_close_config()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=1449-1561) before *later* attempting to call [db_record_repository_filename()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=3042-3045).

db_close_config() is called by [db_close()](https://fossil-scm.org/home/file?name=src/db.c&ci=dcc90ab5e1b49b1b&ln=2129), itself called by [clone_cmd()](https://fossil-scm.org/home/file?name=src/clone.c&ci=dcc90ab5e1b49b1b&ln=170) due to the source repository being a local file.

db_record_repository_filename() is called by [clone_cmd()](https://fossil-scm.org/home/file?name=src/clone.c&ci=dcc90ab5e1b49b1b&ln=172), just two lines after it called db_close().

Gonna work on this some more.

In [multi-remote-fix](http://fossil-scm.org/home/info/719dcd29cd8a99d5), the first major difference I see is db_close() does not call db_close_config() because [g.db is NULL](https://fossil-scm.org/home/file?name=src/db.c&ci=719dcd29cd8a99d5&ln=2090).  Thus, the configuration table is open and the global_config table still exists by the time db_record_repository_filename() tries to access it.

In [trunk](http://fossil-scm.org/home/info/dcc90ab5e1b49b1b), g.db is non-NULL, leading to the errors I've been experiencing, namely the configuration database being closed before db_record_repository_filename() can get to it.

g.db is non-NULL because the multi-remote feature modified url_parse_local() to call db_get() in support of the "URL" actually being the alias for a previously-registered remote URL.

The multi-remotes don't all autosync at once.  Only the default remote syncs.

"[The default remote is used by autosync.](https://fossil-scm.org/home/file?ln=375-376&ci=de38906f&name=src%2Fsync.c)"

I have wanted automatic sync'ing of multiple remotes, but this is not implemented.  See my [thread](/forumpost/e5477060c6) on this topic.

Fixed, thanks again to drh.  ([Check-in](https://fossil-scm.org/home/info/9d2b7cab7ac64cf8))