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

[Overlays] [OS X] Files with SoftErrors have red overlay icon #3944

Closed
ckamm opened this issue Oct 13, 2015 · 3 comments
Closed

[Overlays] [OS X] Files with SoftErrors have red overlay icon #3944

ckamm opened this issue Oct 13, 2015 · 3 comments
Assignees
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Oct 13, 2015

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 subsequent RETRIEVE_FILE_STATUS command would return a different status for it.

@ckamm ckamm added the type:bug label Oct 13, 2015
@ckamm ckamm self-assigned this Oct 13, 2015
@ckamm ckamm added this to the 2.1-next milestone Oct 13, 2015
@ckamm ckamm added the sev4-low label Oct 28, 2015
@guruz guruz changed the title Files with SoftErrors have red overlay icon [Overlays] Files with SoftErrors have red overlay icon Nov 3, 2015
@guruz guruz changed the title [Overlays] Files with SoftErrors have red overlay icon [Overlays] [OS X] Files with SoftErrors have red overlay icon Nov 3, 2015
@guruz guruz modified the milestones: 2.1.2, 2.1-next Nov 3, 2015
@ckamm
Copy link
Contributor Author

ckamm commented Dec 9, 2015

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 RETRIEVE_FILE_STATUS has no idea about that and bases its decision solely on whether the file needs syncing (so erroring files will be shown as "EVAL").

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?

@ckamm
Copy link
Contributor Author

ckamm commented Dec 10, 2015

Actually, this error cache already exists in Folder, it's just buggy.

ckamm added a commit to ckamm/owncloud-client that referenced this issue Dec 10, 2015
ckamm added a commit to ckamm/owncloud-client that referenced this issue Dec 10, 2015
Before we blindly broadcasted the result of a sync action. That was
often different from what a subsequent FILE_STATUS query would report.
ckamm added a commit to ckamm/owncloud-client that referenced this issue Dec 10, 2015
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Dec 10, 2015
@Dianafg76 Dianafg76 added approved by QA and removed ReadyToTest QA, please validate the fix/enhancement labels Dec 11, 2015
@Dianafg76
Copy link

I tested this issue and now is working ok
Desktop v ownCloud-2.1.0.5699-nightly20151211-setup.exe
Server v {"installed":true,"maintenance":false,"version":"8.2.1.4","versionstring":"8.2.1","edition":"Enterprise"}
Closed

jturcotte added a commit that referenced this issue Jan 5, 2016
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants