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

New folders aren't watched immediately, potentially missing notifications #7068

Closed
ckamm opened this issue Mar 5, 2019 · 3 comments
Closed
Assignees
Labels
Linux ReadyToTest QA, please validate the fix/enhancement type:bug
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Mar 5, 2019

Only on Linux:

  1. Create a new folder, wait for a sync to start and finish local discovery.
  2. Before the new folder is processed and gets an inotify watch, add files to it.
  3. The client sync finishes without syncing the new files (as expected)
  4. No new sync will be scheduled and the next sync won't locally discover the new folder (bad)

This will be particularly bad if the user moved files into the new folder within the failure window. Then the next sync will assume these files were deleted and delete them on the server. Only the next full-discovery sync would upload the moved files and correct the issue.

FYI @PVince81

@ckamm ckamm added this to the 2.5.4 milestone Mar 5, 2019
@ckamm ckamm self-assigned this Mar 5, 2019
ckamm added a commit that referenced this issue Mar 5, 2019
There was a period of time between local discovery of a new folder and
the folder receiving a filesystem watcher. Any changes to its contents
during that time were missing, leading to misbehaviors.
ckamm added a commit that referenced this issue Mar 5, 2019
Previously it depended on addFolder() / removeFolder() calls to adjust
watchers when new folders were added or removed. There also needed to be
complex move handling.

Now, any folder creation/move-in notifications automatically trigger
watcher additions and folder deletion/move-out triggers removal.
ckamm added a commit that referenced this issue Mar 5, 2019
Previously it depended on addFolder() / removeFolder() calls to adjust
watchers when new folders were added or removed. There also needed to be
complex move handling.

Now, any folder creation/move-in notifications automatically trigger
watcher additions and folder deletion/move-out triggers removal.
ckamm added a commit that referenced this issue Mar 7, 2019
There was a period of time between local discovery of a new folder and
the folder receiving a filesystem watcher. Any changes to its contents
during that time were missing, leading to misbehaviors.
@ckamm ckamm added ReadyToTest QA, please validate the fix/enhancement and removed PR available labels Mar 7, 2019
@guruz
Copy link
Contributor

guruz commented Mar 11, 2019

ckamm added a commit that referenced this issue Mar 14, 2019
Previously it depended on addFolder() / removeFolder() calls to adjust
watchers when new folders were added or removed. There also needed to be
complex move handling.

Now, any folder creation/move-in notifications automatically trigger
watcher additions and folder deletion/move-out triggers removal.
@lazawan
Copy link

lazawan commented Mar 15, 2019

@ckamm i tried to reproduce the bug on client 2.5.3 but i did not manage it (on ubuntu 16.04)
here what i did :
i limited the bandwidth in order that sync is slower
i pasted a folder with files into sync folder
during sync i added files into the new pasted folder
but the files that i added afterwards ,were synchronized too
did i do that what you meant ?

@ckamm
Copy link
Contributor Author

ckamm commented Mar 15, 2019

@lazawan That depends on when exactly you pasted the new files, it needs to happen before the creation of the new folder on the server is completed. Propagation of the contents of the folder happens afterwards. Possibly adding large files to the sync root might do it, but it could depend on job ordering. I'll look more closely tomorrow.

@ckamm ckamm closed this as completed Apr 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linux ReadyToTest QA, please validate the fix/enhancement type:bug
Projects
None yet
Development

No branches or pull requests

3 participants