Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A file deleted from all nodes may exist in the "out of sync" list #4627

Closed
TianyiChen opened this Issue Dec 31, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@TianyiChen
Copy link

TianyiChen commented Dec 31, 2017

When a file is deleted from the slave first, and then from the read-only master. It disappeared and later existed again in the "out of sync" list on the master. I feel it should be excluded permanently in the list.

My steps to reproduce:

  • Create 4 files 0, 1, 2, 3 on the master node. Set the folder in the master to be "send only"
  • Do an initial synchronization
  • Delete 2, 3 on the slave
  • Rescan on the slave and synchronize
  • Delete 1, 2 on the master
  • Pause and resume on the master (optional)
  • The "out of sync" list shows only 3
  • Later (I tried 3 times)
    • In 2 attempts, the final list showed after a pause and a resume
    • In 1 attempt, I paused and resumed several times before seeing the count of "out of sync" list to be 2
  • Now we have 0, 3 on the master and 0 on the slave
  • Eventually the "out of sync" list shows 2 and 3. Since 2 is already deleted from the master and the slave, I think it shouldn't appear here

I tried to restart Syncthing or the operation system, but the problem persisted

Screenshots from the master:

untitled

untitled2

Version Information

Syncthing Version: v0.14.42
OS Version:

Master: Windows7 (64-bit) Slave: Android 7.1
I also encountered a similar issue with Master: Android 4.4 Slave: Android 7.1

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Dec 31, 2017

Sorry, what's the issue, you deleted 2, 3 on slave, and master refuses to accept that (as it's master), hence becomes out of sync.

Anyways, support is handled on the forums.

@TianyiChen

This comment has been minimized.

Copy link
Author

TianyiChen commented Dec 31, 2017

I know that the state of out of sync is expected in this case. 2 is deleted from the slave and the master so it no longer exists, should it still exist in the out of sync list? Also it seems inconsistent that 2 is excluded in the count of global and local state but included in the out of sync list.

If this scenario is unexpected, then this is a bug report. Otherwise, this is a feature request because an updated list may be useful when solving the out of sync.

@AudriusButkevicius

This comment has been minimized.

Copy link
Member

AudriusButkevicius commented Dec 31, 2017

Logically it doesn't make sense, yet technically because even the state is the same, the action is initiated by different devices, hence it's out of sync.
I'll leave for @calmh to answer.

@calmh

This comment has been minimized.

Copy link
Member

calmh commented Dec 31, 2017

No, it’s a bug. What should logically happen I think is

  1. Things are in sync
  2. File deleted in normal folder, other device with send only folder is out of sync. (“Override” would resurrect)
  3. File deleted in send only folder. Things are in sync.

It’s similar to the other issue when a new device with identical contents coming online will make a send only device fully out of sync.

We should resolve the differences as long as it doesn’t result in differences on disk for the send only folder.

Currently we have to press override now and then just for internal metadata reasons, which is ugly.

@calmh calmh reopened this Dec 31, 2017

imsodin added a commit to imsodin/syncthing that referenced this issue Feb 10, 2018

lib: Handle metadata changes for send-only folders (fixes syncthing#4616
, fixes syncthing#4627)

Unignores files while scanning (previously while pulling in rw folder), such
that it happens regardless of folder type. Automatically reconciles needed items
on send-only folders, if they do not actually differ except for internal
metadata.

imsodin added a commit to imsodin/syncthing that referenced this issue Feb 10, 2018

lib: Handle metadata changes for send-only folders (fixes syncthing#4616
, fixes syncthing#4627)

Unignored files are marked as conflicting while scanning, which is then resolved
in the subsequent pull. Automatically reconciles needed items on send-only
folders, if they do not actually differ except for internal metadata.

@calmh calmh closed this in 158859a Feb 25, 2018

@calmh calmh added this to the v0.14.46 milestone Feb 25, 2018

@calmh calmh added the bug label Feb 25, 2018

calmh added a commit to calmh/syncthing that referenced this issue Mar 11, 2018

Merge branch 'master' into varblocks
* master: (31 commits)
  cmd/syncthing, lib/db: Be nicer about dropping deltas on upgrade (syncthing#4798)
  gui, man: Update docs & translations
  cmd/stdiscosrv: Record time of failed lookup
  cmd/stdiscosrv: Expose process metrics
  test: Update conflict tests
  gui: In remote need use index and auto-expand if only one folder (fixes syncthing#4759) (syncthing#4781)
  gui, man: Update docs & translations
  cmd/syncthing: Reset delta indexes on upgrade
  lib/connections: Fix relay connections when two devices use the same relay (fixes syncthing#4778) (syncthing#4779)
  lib/scanner: Track modified by in symlinks (syncthing#4777)
  lib/model: Mark deleted file as conflicting when un-ignoring (syncthing#4776)
  lib/config, lib/model: Auto adjust pullers based on desired amount of pending data (syncthing#4748)
  lib: Handle metadata changes for send-only folders (fixes syncthing#4616, fixes syncthing#4627) (syncthing#4750)
  lib/model: More precise deletion detection (fixes syncthing#2571, fixes syncthing#4573) (syncthing#4765)
  lib/model: Don't panic if block size in index is larger than protocol block size
  all: Fix typos (syncthing#4772)
  cmd/strelaysrv: Don't patch the default HTTP client (fixes syncthing#4745)
  cmd/strelaypoolsrv: Return better error codes and messages (syncthing#4770)
  lib/fs, vendor: s/zillode/Zillode/
  cmd/syncthing: Fix help text for STRECHECKDBEVERY (fixes syncthing#4764)
  ...
@tr37ion

This comment has been minimized.

Copy link

tr37ion commented Aug 5, 2018

For me, is not fixed with v0.14.49 Linux (64 bit). Regression?

@imsodin

This comment has been minimized.

Copy link
Member

imsodin commented Aug 5, 2018

For me the steps above result in the expected up-to-date state. Please post on forum.syncthing.net until we identified and reproduced the problem.

@tr37ion

This comment has been minimized.

Copy link

tr37ion commented Aug 6, 2018

From what I remember, I did try ...

  1. Copying a large (5GB) folder with many small files into my sync folder of host A.
  2. Then Syncthing picked it up and started syncing.
  3. After quite some time (still in sync process) I had to leave and I decided to delete the folder
  4. Therefore, I did delete the folder on A - with the hope Syncthing would instantly stop syncing and deelte everything on target host B
  5. Well, This took a lot longer than expected - I had to leave - So, I just deleted the folder on B, too. (half-synced)

.. and I think at that point I did mess up something. As this resulted in Syncthing keeping the missing files as "unsynced" state. Which is quite obvious, as the source wasn't present anymore and the marked files for deletion weren't there either.

@imsodin

This comment has been minimized.

Copy link
Member

imsodin commented Aug 6, 2018

Ok, then lets move any further discussion to forum.syncthing.net please. This doesn't look like it's the same as this issue. If the cause (or reproducer) can be found, then a new issue can be opened.

@syncthing syncthing locked and limited conversation to collaborators Feb 26, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.