Here again is the database and a screenshot of the out-of-sync items from the LenovoX1. These are only minutes apart, with no change to the folder. Syncthing was restarted immediately beforehand.
LenovoX1.tar.gz (187.5 KB)
In this case it’s at least consistent: it looks like the encrypted side hasn’t applied or announced the deleted file. It still announces the previous non-deleted version.
Thanks for your analysis and persistence. Is there anything else that I can do that might help?
Logs from the encrypted node might help.
Sure, which ones, howto, and before or after files/folders change?
I’m wondering if the issue relates to the length of the path/filenames, which might exceed the capability of the sqlite database.
On the same partition on all three devices and shared send-receive is the already encrypted restic repository, which has similar length paths and filenames, but does not carry the extra burden and longer file names of encryption imposed by receive-encrypted*. The repository is much larger than the cache, having all the data backed up, and also changes frequently with each backup cycle. There is no issue with this folder.
*Encrypted file names like this: PH8OBP0HGR6P1QIJCTP7IP0G92FN9NN18M452441M8UGQGAFR2ICSI7P0S79LON683IJJ0G2SMC72GD58JAMBG7NJIKRJJ122I45OQQHIM72PPMCFEABR602US8P00AA8OM4TR7ME3ETBN1V7Q7QME91ABA6OO80Q0Q9UB4DSIV7GMP358K4OGGSVOMF6725IP51PU42
There is no need for the restic-cache to be encrypted (as it already is by restic). I had only located in the receive-encrypted folder ‘Techie’ for convenience. The restic-cache folder is now separate and is the only folder exhibiting the issue in question. The partitions on all three devices are btrfs.
I’ll change the restic-cache folder to send-receive, wait for a couple of backup cycles, and report back.
Any thoughts?
Edit: several restic backup cycles later (8 hours) and there are no out-of-sync 0b files.
It’s for sure not the file name length. TBH I don’t think it’s a v2 database thing at all, I think it’s a corner case / bug in the encrypted stuff that’s separate…
I have had the arrangement working successfully for several year with v1 leveldb without any errors. The issues only emerged immediately after I committed to v2. Surely, there is some interaction between v2 database and ‘encrypted stuff’ at play?
Thanks again @calmh for your persistence and insights. I was hoping to help resolve this before v2 goes mainstream. I thought the long path/filename might be a clue given that other recieve-encrypted folders (Thunderbird profile/Techie) are shared the same way and don’t create out-of-sync errors.
The other clue is that all the files are 0 byte files deleted on one side and the actual global and local states are equal on each device.
Certainly the encrypted items are stored in the database, same as they always were. It’s just that there are a lot of bug reports of encrypted shares stuck at 95% for deleted items both here and on GitHub for v1. I’m not sure why it worked previously for you and now don’t, clearly something changed, but there are definitely v1 issues here already present. 
1 Like
Thanks again. I’m not getting any errors now that restic-cache is shared unencrypted. Looking forward to the production release. Syncthing is an indispensable part of my computer world.
1 Like