Ghost "local changes" on untrusted device

I’m running an untrusted device (v1.20.3, Linux (32-bit ARM)) as a destination to files which replicate elsewhere (to other trusted) devices.

Occasionally, the untrusted device will show that there are “local changes” and give me the option to revert them.

  1. There haven’t been any local changes. I can be certain about this because it’s dedicated headless device with only syncthing running on it.

  2. The files that have been listed under “Locally Changed Items” have size 0 and they are actually not present on the file system

  3. Hitting Revert Local Changes doesn’t resolve the problem. Also tested “reset-deltas”

0-byte-sized files usually mean deleted files in Syncthing. If that’s the case, Syncthing seems to be complaining about files that aren’t present in the system, even though they should be.

What does the log say after you try to “Revert Local Changes”?

This is in the logs:

2022-07-25 14:03:52 receiveencrypted/hj54d-0ym5q@0x3aaa960 Running something due to request
2022-07-25 14:03:52 Reverting unexpected items in folder "##### NAME #####" (hj54d-0ym5q) (receive-encrypted)
2022-07-25 14:03:52 log 14679 StateChanged map[duration:693.324620544 folder:hj54d-0ym5q from:idle to:scanning]
2022-07-25 14:03:52 log 14680 StateChanged map[duration:0.955257592 folder:hj54d-0ym5q from:scanning to:idle]

Could you get us some debug info on one or two of the items listed by running

syncthing cli debug file FOLDER-ID PATH

with FOLDER-ID and PATH (relative to folder root path) replaced with the actual values.

Hi Simon, thanks for providing debug steps.

I’m actually currently facing another unresolved issue with same folder & devices. I’m not sure if the original issue is still present or if both issues are related.

Currently, getting this error:

2022-08-01 22:13:30 close due to handling index-update for aaaaa-zzzzz: data too short

Providing both device logs. Sender is Android, the untrusted device is Linux.

sending_device.log (4.6 KB) untruste_device.log (10.0 KB)

Also probably worth mentioning, the same folder replicates to another unencrypted device. There it fails to replicate files that no longer exist and have 0 size.