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

Sharing: fix overlay icons directly after sharing a file #6115

Merged
merged 4 commits into from
Oct 24, 2017
Merged

Conversation

ogoffart
Copy link
Contributor

See commit message for more information.
The two first commit are just code cleanup
The other commit fix the issue #6098

This include a workaround of the fact that the server don't update the etags.

It is growing indefinitively in case of error, causing a leak.
Use a labda instead to pass the capture
... even if the file is not changed.

We get an UPDATE_METADATA in that case, so make sure we let the
SyncFileStatusTracker know about it.
That means we need to filter out UPDATE_METADATA in the other listeners
of this signal.

Issue #6098
This allow the sync engine to query the new metadata and update the
overlay icons.

Note: we also need to invalidate the etags because the server does not
change the etag of parent directories that see their share-types changed.

Issue #6098
@ogoffart ogoffart requested review from ckamm and jturcotte October 23, 2017 17:16
if (item->_instruction == CSYNC_INSTRUCTION_NONE || item->_instruction == CSYNC_INSTRUCTION_UPDATE_METADATA) {
// We only care about the updates that deserve to be shown in the UI
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including CSYNC_INSTRUCTION_NONE sounds wrong, would it be possible to check at the emit point?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CSYNC_INSTRUCTION_NONE should never happen. But i'm putting it there as it goes hand to hand with UPDATE_METADATA. (Should the sync engine change, and emit the signal with CSYNC_INSTRUCTION_NONE in the future, we probably want to filter it there anyway)
I could remove it from this check if you think this is confusing.

Copy link
Member

@jturcotte jturcotte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've always like the comforting thought that CSYNC_INSTRUCTION_NONE just means invalid post-reconcile, but I do already check for it in SyncFileStatusTracker for discovered and completed slots. So I guess it's better to include it.
👍

@ogoffart ogoffart merged commit c36043a into 2.4 Oct 24, 2017
@ogoffart ogoffart deleted the sharing branch October 24, 2017 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants