[macOS] csync errors do not appear in new error view and block the sync process

@ckamm

I was testing testing out the before/after of applying #5875 on the client under macOS and noticed a couple of odd behaviors there:

Expected behavior

The [ warning sync.csync ]: Invalid characters in file/directory name, please rename: "💃" (/Users/<user>/ownCloud) propagates to the new "List of Issues" (Add a more functional error view #5516 #5861) under the "Not Synced" tab
The overlay icon of the erroneous file switches to ❌
The sync operation is not blocked by it -> Never ever abort sync runs / check that the connection is indeed broken before aborting on a timeout #5859

Actual behavior

Error does not appear on the new section, even though section is properly displayed after IssuesTab: Hide folder and account filters if they aren't useful #5881 (before the error it wasn't) - Shouldn't be also labeled as error instead of warning?
Overlay of the file stays 🔄
The sync is blocked by the error

Steps to reproduce

Use a client that does not contain csync: Use Qt for encoding conversion instead of iconv #5875
Create a local folder with an emoji as filename "💃"
See the account tab

I know the specific issue about the file name encoding will be solved after #5875 and I still need to check if other csync warnings display the same behavior and if it also happens on different platforms.

cc/ @ckamm @guruz as you implemented #5861 and @jturcotte for the overlay magic

@SamuAlfageme

@SamuAlfageme You're quick; I think I've already addressed the issue with the errors tab in a local patch and thought I could fix it without anyone noticing. :)

The overlay or sync-aborting properties are independent of that though.

EDIT: PR that has the fix: #5890

The "csync errors don't appear in new error view" is addressed, the "block the sync process" isn't addressed.

Invalid characters in file/directory name, please rename

FYI That error is created early by the csync discovery already, not by an individual upload job.

Also note that with 2.4 emojis won't block the sync, but invalid utf8 still will (i think)

Even then, emoji in filenames should not have been blocking the sync for a long time. What makes you think the sync is blocked? The red just say there was an error during the sync, but the sync should have completed

@ogoffart

07-21 16:18:00:650 0x7f8936f737f8 csync_vio_local_readdir: Invalid characters in file/directory name, please rename: "💩.txt" (/Users/guruz/ownCloud_oli)
07-21 16:18:00:650 0x7f8936f737f8 csync_statedb_close: sqlite3_close=0
07-21 16:18:00:655 22487 OCC::SyncEngine::handleSyncError:  #### ERROR during  csync_update :  "Invalid characters, please rename \"/Users/guruz/ownCloud_oli/💩.txt\""
07-21 16:18:00:655 22487 OCC::SyncJournalDb::close: void OCC::SyncJournalDb::close() "/Users/guruz/ownCloud_oli/._sync_edb0e5c1444c.db"
07-21 16:18:00:655 22487 OCC::SyncJournalDb::commitTransaction: No database Transaction to commit
07-21 16:18:00:656 22487 OCC::SyncEngine::finalize: CSync run took  8
07-21 16:18:00:656 22487 OCC::Folder::slotSyncFinished:  - client version 2.3.3git  Qt 5.6.2  SSL  OpenSSL 1.0.2j  26 Sep 2016
07-21 16:18:00:656 22487 OCC::Folder::slotSyncFinished: -> SyncEngine finished with ERROR
07-21 16:18:00:656 22487 OCC::Folder::showSyncResultPopup: OO folder slotSyncFinished: result:  2
07-21 16:18:00:656 22487 OCC::Folder::slotSyncFinished:     * owncloud csync thread finished with error
07-21 16:18:00:656 22487 OCC::Folder::slotSyncFinished: the last 2 syncs failed

(This is 2.3 branch before @ogoffart 's patch)

@guruz

@guruz I'm not sure which patch you're referring to. Your log output suggests that this is indeed an error that will abort the whole sync run after the discovery phase? This part of this issue doesn't seem fixed. (but I'd need osx to verify)

@guruz

@guruz. Right, it was aborting the sync.
But this should not happen anymore with all the refactoring, normally. Does it?
Or what is this bug about really?

Yes, this seems to have happened when csync_vio_local_readdir encounters a dirent->d_name that c_utf8_from_locale can't convert. However, I don't see how that function would return an empty string on OSX in the current version of the code unless the input is null.

@SamuAlfageme

@SamuAlfageme Is this reproducible with 2.4?

Right, 2.3 might have had the issue (i tought it was fixed, but there was a goto error that broke it)
Anyway, 2.4 should now really be fixed.

Not reproducible anymore - tested out against a huge list of unicode random strings accepted by HFS+/APFS and neither errors were raised in the client side, nor the sync was locked at any point.

🤙 Close here

Navigation Menu

Repository navigation

[macOS] csync errors do not appear in new error view and block the sync process #5888

Expected behavior

Actual behavior

Steps to reproduce

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[macOS] csync errors do not appear in new error view and block the sync process #5888

Description

Expected behavior

Actual behavior

Steps to reproduce

Activity

ckamm commented on Jul 11, 2017

ckamm commented on Jul 21, 2017

guruz commented on Jul 21, 2017

ogoffart commented on Jul 21, 2017

guruz commented on Jul 21, 2017

ckamm commented on Oct 11, 2017

ogoffart commented on Oct 17, 2017

ckamm commented on Oct 24, 2017

ckamm commented on Oct 26, 2017

ogoffart commented on Nov 28, 2017

SamuAlfageme commented on Dec 12, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions