Receive only folder out of sync

Support
1

I’m seeing frequently “out of sync” for a receive-only folder, asking me to “Revert local changes”, which is unreasonable since receive only folder should always revert local changes IMO. I tried pressing “Revert local changes” but it only does a rescan and returns to “out of sync”.

Also failed items have errors like:

  • directory is not empty
  • peers who had this file went away, or the file has changed while syncing. will retry later

What should I do to resolve this?

2

Well, that’s a choice, and according to Syncthing’s first goal (data safety) the choice was made to not automatically destroy data.

That’s bad - you can enable the model debug facility and post logs from that process (actions->logs) and I can have a look.

That shouldn’t happen: Can you check what is in this directory, both on this and connected devices.

Do you have disconnected devices? Then these might be files that only those devices have (and thus can’t be synced until they reconnect).

3

Here’s the folder and its files that’s prompting directory not empty:

ProgramData/Microsoft/Windows/Start Menu/Programs/Killer Networking/
ProgramData/Microsoft/Windows/Start Menu/Programs/Killer Networking/Killer Diagnostics.lnk
ProgramData/Microsoft/Windows/Start Menu/Programs/Killer Networking/Killer Control Center.lnk

There are only two devices for that folder, one sender and one receiver. I’m guessing it’s a race condition (sender deleted the file before it was able to send it/sync it to the database?).

As for model debug facility, I’ll go reboot syncthing and see how that goes.

4

Is the directory actually deleted on the sender? Any ignore patterns in effect?

Such a race isn’t a possibility, deleted files are registered by them being missing.

Also please specify the Syncthing version you are using.

5

Is the directory actually deleted on the sender? Any ignore patterns in effect?

Yes and yes. I’ll attach .stignore here:

*.log.*
*.log
*Cache
*.old
/Users/Mygod/AppData/Local/Google
/Users/Mygod/AppData/Local/Syncthing/*.db
/Users/Mygod/AppData/Local/Packages/Microsoft.Windows.Cortana*
!/ProgramData
!/Users/Mygod
/**

Such a race isn’t a possibility, deleted files are registered by them being missing.

Okay. I just checked and those files seem to be present on the sender (send only) side and it’s not ignored by .stignore (I think). Path name is Users/Mygod/AppData/Local/Packages/Microsoft.LockApp_cw5n1h2txyewy/Settings/settings.dat.

Also please specify the Syncthing version you are using.

Yes, sorry. It’s v1.0.0. I have auto update on.

Here is log after pressing “Revert local changes”: http://cryptb.in/hVVDV#b95c896ee71ac4353d7f6f98e62e714d (valid for at most 3 days)

6

Any ideas?

7

The logs aren’t accessible anymore (and I didn’t manage to get them in plain text when I tried some days ago). And I am confused by your paths:

I am interested in the paths related to directory not empty and their actual existence on both systems. Also it seems to be send-only to receive-only, correct?

About the peers who had ... thing: Does it go away when you pause and resume the folder? There is a bug fixed in the next version that might cause this - it’s rather unlikely but possible.

8

So I updated to v1.0.1-rc.2 on both sides. The syncing seems to work much better now but those items are still failing. Logs on receiver: http://cryptb.in/T1L8#441dacd9ad03afbb3d527173231c3420 (this time 7 days)

Let me try to explain things clearer this time.

directory not empty

Sample path: Users/Mygod/AppData/Local/Microsoft/Terminal Server Client

Availability on sender: Directory does not exist

Receiver:

$ find 'Users/Mygod/AppData/Local/Microsoft/Terminal Server Client'
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client/Cache
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client/Cache/Cache0003.bin
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client/Cache/Cache0000.bin
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client/Cache/bcache24.bmc
Users/Mygod/AppData/Local/Microsoft/Terminal Server Client/Cache/Cache0002.bin

The directory has always been managed by syncthing.

peers who had this file went away, or the file has changed while syncing. will retry later

Sample path: Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/settings.dat.LOG2

Availability on sender: In that folder, there’s only roaming.lock and settings.dat.

Receiver:

$ find 'Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings'
Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings
Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/settings.dat.LOG1
Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/.syncthing.settings.dat.LOG2.tmp
Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/settings.dat
Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/roaming.lock

I think these are caused by race conditions (files were updated while syncthing is performing scans, etc.).

Pausing and resuming both sides doesn’t help. Thanks for your help!

9

For the peer not found part the relevant line in the log is:

2019-01-20 16:21:49 request: utrwq-6rcj5 Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/settings.dat.LOG2 0 8192 returned error: generic error

This indicates that the sender failed to read the file. As it looks like a log file, I’d assume there is some kind of lock on the sending side on it.

Regarding directory is not empty: The files you found are all ignored according to your previous post, but apparently they are not ignored. Make sure in the web UI that on both sender and receiver these ignores are actually the same as in your post here.

10

Hmm, however, that file does not exist on receiver.

11

I removed the ignored files. Now there are 19 locally changed items and 1 failed items. One example of locally changed item is: Users/Mygod/AppData/Local/Adobe/Acrobat/DC/UserImageAcrbt.

12

That’s what I am saying: The sender can’t read it, so the data isn’t sent to the receiver so obviously the receiver doesn’t have it.

Why? Did you check ignores? What am I to do with this new path?
Sorry for being a bit harsh, but your reactions (as in no reactions to my specific advice/questions) make me feel like wasting my time.

13

My apologies. I felt a little tired earlier so I forgot to update you with the not found errors. I updated the ignore rules and removed those files manually and I think that takes care of it. Thank you for the help!

That’s what I am saying: The sender can’t read it, so the data isn’t sent to the receiver so obviously the receiver doesn’t have it.

So what am I supposed to do when that happens? Do I have to remove the syncthing temp file manually even though that file is already gone?

Let me clarify a little here. 1 failed item refers to the error peers who had this file went away, or the file has changed while syncing. will retry later and the other errors are gone for now. I just discovered that there are also 19 locally changed files that are not reverted for some reasons… So for these files, they seem to be present on both ends so I’m not sure what’s wrong…

14

Nice to hear it works. Just updating the ignore rules (potentially adding a (?d) prefix) should have done the job without any manual deleting, that’s why I asked.

You don’t need to handle temp files - if they are unused Syncthing automatically removes them after 24h.

In the specific example of Users/Mygod/AppData/Local/Packages/AcrobatNotificationClient_e1rzdqpraam7r/Settings/settings.dat.LOG2 the problem probably was that the file isn’t readable by the sender. You can ignore it, you can check why it isn’t readable, maybe some adobe program is running, then you can stop that program and the error will go away. There is not one-answer fits all for this kind of error, you need to check the files that are reported.

If you share between windows and linux/mac/… then the problem might also be case sensitivity, but I don’t think that’s the case for you (?).

I am not quite sure what you mean by the locally changed files: Do they also have the peers who had... error message, the only difference being the already exist on receiver? If that’s the case there is no difference at all to what I wrote above, it is the same whether the file already exists and is changed or doesn’t exist at all.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.