[Done] Request for input from "receive-encrypted" users

No action needed anymore, issue was found.

I could use some feedback/help from users using the receive-encrypted folder types (reminder: That feature is still in testing/beta):

If you are already using RCs, please report if you see any issues with v1.23.3-rc.1.

If you are on the stable release and can afford to potentially break the receive-encrypted side (i.e. you shouldn’t have to, but might need to resync everything on that side) and have a bit of time, it would be great if you could do the following:

  1. Create a backup of your config and db (in a default setup, just copy the entire ~/.config/syncthing directory).
  2. Upgrade both devices (trusted and untrusted/receive-encrypted) to the RC.
  3. If you encounter any weird behaviour during/right after the upgrade: After you are certain the upgrade is done everywhere, rescan the folders (or start/stop the folder or restart syncthing).

Then please report here, also if everything went smoothly. If you had issues, please post screenshots/descriptions of them.

If you want to dive deeper, check out the original report that prompted me to call for help here: V1.23.3-rc.1 and Received Encrypted

2 Likes

For what it’s worth, some of the described issues from that topic seem -sort of- reproducible in my environment (half virtual, half physical). At least the local state of having unexpected items when using touch on them seems to be a 100% chance to come across (remote devices too, but that seems quite a logic consequence).

If I follow the following steps, I always end up having Unexpected items;

[both device A (Ubuntu Server 22.04 and MacOS 13.2.1) and B (Ubuntu Client 22.04) are on 1.23.3-rc.1]

  • Device A: Share folder A to device B and set a password
  • Device B: accept it (sidenote: this step required device A to pause and unpause the folder, otherwise it kept hanging in a ‘device B did not accept…’-state.)
  • Device A: create a file
  • [Wait for a full sync]
  • Device A: Touch the added file
  • Device A: full rescan
  • Device B: full rescan
  • Device B: Unexpected items…
  • (Note: I’m not sure how the encrypted mode works exactly, so this may be irrelevant, but the changed mod-time also did not get synced here, where it normally would have)
  • If you now touch once more and repeat the rescanning on device A, even reverting the local changes on device B will get stuck and the folder will have to be paused/unpaused on device B for it to get unstuck. If this happens, Device B thinks that it has 2 local files, while this is not the case. Doing more touches won’t change this btw.
4 Likes

Woopwoop, got it. So the crucial bit was “touching” the file, not changing the data. That’s why I couldn’t repro so far. Behaviour for me is still not entirely the same, but it was broken enough to find the cause (and another bug).

What happens for me, just for completeness:

  1. Touch the file (important that it’s just mod. time, editing the file works just fine for me), rescan on a: B still in syny.
  2. Rescan on B: local changes
  3. revert on B: all good again, also further rescans are fine.
  4. Touch again on A and scan → same as 2. and 3., so revert keeps working.

Fix for what we observe here: lib/model: Fix file size inconsistency due to enc. trailer by imsodin · Pull Request #8840 · syncthing/syncthing · GitHub
Another bugfix for the same original PR (i.e. for the RC too): lib/model: Set enc. trailer size on pull (ref #8563, #8556) by imsodin · Pull Request #8839 · syncthing/syncthing · GitHub

6 Likes

Nice detective work, everyone. :saluting_face:

2 Likes