Repository: syncthing/syncthing (language: go)

Issue:
Deadlocks randomly, occasionally 
### What happened?

Situation: I have 'bout a dozen servers syncing some files with Syncthing. All are on Debian 12. Never a real issue, but right after update to 1.29.0 strange things happen (one or more at the same time):

* Hosts are marked as "synchronizing" and/or a few files unable to sync (which aren't present on either the host itself or the host that it displays that the missing file would be present)
* Syncthing processes just stop responding (no more loglines in syslog)
* All shared resources on a host are marked "unavailable" (but the files are just there)

Restarting syncthing resolves it, but it returns after a random amount of time.

Have downgraded syncthing to 1.28.1 on the hosts 5 hours ago and 0 issues since then.

Submitting the report in case others experience the same behaviour since 1.29.0 and maybe a common denominator can be found.

### Syncthing version

v1.29.0

### Platform & operating system

Linux amd64 (Debian 12 Bookworm) - installed through official syncthing repo

### Browser version

Firefox 133.0.3

### Relevant log output

```shell
No logs; just stops logging in syslog. Process isn't crashed (web interface still works), but a restart is necessary
```



Discussion / hints:
It also appeared on centos 7
I think we need a goroutine dump from a hung instance to figure out what's going on. When it's in a bad state, figure out the pid of the processes; there will be two of them (plus maybe the grep etc):

```
jb@jbo2:~ % ps aux | grep syncthing
jb               87691   0.0  0.7 412468848 267104   ??  SN    8:02AM   2:08.77 /Users/jb/bin/syncthing
jb               87690   0.0  0.0 411936912   9312   ??  S     8:02AM   0:00.32 /Users/jb/bin/syncthing
jb               91971   0.0  0.0 410060064     32 s000  S+   11:16AM   0:00.00 grep syncthing
```

Take the higher PID of the two and send it a SIGQUIT:

```
jb@jbo2:~ % kill -QUIT 87691
```

You'll get a very long thread/routine dump in the log output. Where that is depends on how it's set up, but wherever you get Syncthing logs. Upload the whole thing...
It also appeared on Debian 11.9
Also in Arch (6.12.8-arch1-1 and 6.6.69-1-lts).  Since I was in a hurry I just downgraded, 1.28.1 works.
> You'll get a very long thread/routine dump in the log output. Where that is depends on how it's set up, but wherever you get Syncthing logs. Upload the whole thing...

I'm having a quite similar issue, and got a dump following this step. Could you check if this log is useful?
[syncthing-hang.log](https://github.com/user-attachments/files/18364821/syncthing-hang.log)

I'm using [syncthing](https://archlinux.org/packages/extra/x86_64/syncthing/) package on Arch Linux.

Fix patch:
diff --git a/lib/db/meta.go b/lib/db/meta.go
index ece2b07ad14..fd7ec1fce77 100644
--- a/lib/db/meta.go
+++ b/lib/db/meta.go
@@ -76,11 +76,12 @@ func (m *metadataTracker) Unmarshal(bs []byte) error {
 	return nil
 }
 
-// Marshal returns the protobuf representation of the metadataTracker
-func (m *metadataTracker) Marshal() ([]byte, error) {
+// protoMarshal returns the protobuf representation of the metadataTracker.
+// Must be called with the read lock held.
+func (m *metadataTracker) protoMarshal() ([]byte, error) {
 	dbc := &dbproto.CountsSet{
 		Counts:  make([]*dbproto.Counts, len(m.counts.Counts)),
-		Created: m.Created().UnixNano(),
+		Created: m.counts.Created,
 	}
 	for i, c := range m.counts.Counts {
 		dbc.Counts[i] = c.toWire()
@@ -109,7 +110,7 @@ func (m *metadataTracker) toDB(t backend.WriteTransaction, folder []byte) error
 		return nil
 	}
 
-	bs, err := m.Marshal()
+	bs, err := m.protoMarshal()
 	if err != nil {
 		return err
 	}


Test patch: