-
Notifications
You must be signed in to change notification settings - Fork 668
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
[Overlays] [OS X] Files with SoftErrors have red overlay icon #3944
Comments
Currently the socket api is a bit confused when it comes to sync errors on files: The moment a sync item fails with anything but success, we communicate "ERROR" to the clients. But I think we would like to show the error overlay for files with important sync errors. To do that, we'd need to cache which files are affected in this way somewhere. Then fileStatus queries and status broadcasts could be consistent. @dragotin Do you agree with this? |
Actually, this error cache already exists in Folder, it's just buggy. |
Before we blindly broadcasted the result of a sync action. That was often different from what a subsequent FILE_STATUS query would report.
I tested this issue and now is working ok |
Since the presence of any path in SyncEngine::_syncedItems would translate in a SYNC status, platforms that don't refresh all their status cache after an UPDATE_VIEW message like OS X or Windows would keep displaying that status even after all files are successfully synchronized. - Read SyncFileItem::_status to determine the status to display mid-sync - Match moved paths also to _renameTarget since this might be the path to match - Make sure that PropagateDirectory jobs also set SyncFileItem::_status properly
In #3387 we saw that the "423 Locked" error was treated as a SoftError but nevertheless lead to a red overlay icon for the affected folder on Mac. On Linux/nautilus the correct blue icon was displayed.
The underlying bug is in how the client reports completed sync jobs via the socket api. Currently any non-success leads to
ERROR
messages for the file or folder - even when a subsequentRETRIEVE_FILE_STATUS
command would return a different status for it.The text was updated successfully, but these errors were encountered: