Desktop App Synchronisation Failed and Starts to Delete Files

[l33]

I am testing OpenCloud as a replacement for my home NAS which was mostly serving files with Samba. I am still having trouble ingesting all the files. Even after 2 days OpenCloud is still not ingesting and still not showing all files. It is doing so at a rate of about 30 MiB/s and I wonder why it seems to read all data of all files. For example I saw it reading large dmg files. I thought it would be sufficient to read only metadata.

Anyway, in the mean time I started testing the macOS desktop app. There are a few quirks I notice which I have not yet pinned to the source of the problem:

1. Synchronisation seem to stop every now and then and starts to resume after a few minutes.
2. Sometimes, mostly after waking up from macOS stand-by, I find the connection is lost and there is no way to establish it other than restarting the desktop app. The desktop app does not actually try to reconnect to the server when told so. The server logs stays empty and so does the desktop apps log. There are logs from until that point, I can post them once I removed private bits from them.
3. The worst part, however, is that somewhere in the server failing during ingestion of files due to OOM (this is on a 4 GB machine), the desktop app started to delete files on the server. It seems it is in a state where it believes to have already synchronised folders where it has not and consequently removes files on the server. I am not sure how the app got into this state. Once noticed I stopped the synchronisation and have not resumed since.

I think the desktop app should never delete files remotely if synchronisation errors occurred, so I want to find the source of the problem. Any help in doing so is appreciated. I would like to post logs but they contain filenames which I would rather not publish. Is there any tool to strip them and other possibly sensitive parts?

[l33]

I dug a bit into what is happening with the desktop app deleting files. It turns out this is a file name encoding issue. The files on the server were put directly into the data directory and assimilated by OpenCloud. The desktop app downloads the file but writes it locally using a "different" name. Technically the file name is different but the rendered characters are the same. It then uploads the file to the server, since this is a "new" file, and then goes on to remove the original file from the server since there is no such file locally. By doing so it effectively normalizes the filename.

I am not sure if this is intended behaviour. It is at least very irritating for users. It is surely a waste of resources because the desktop app duplicates data on the server.

The original file name on the server was ō (o plus a combining macron) while the new name on the client is ō (o with macron) which is also the new name on the server.

[micbar]

@TheOneRing @dragotin What do you think?

[TheOneRing]

Sounds like a server bug, the server does not serve normalized utf8 encode files.

[l33]

I suspect it is the client that does the normalisation but so far I have been unable to collect any evidence on this claim.

[l33]

Here is an excerpt of the client log. In the log I have rewritten the original file name to ō_orig and the normalised file name to ō_mod so the different names can be better identified as such. It appears that the client is indeed starting with the original but then switches to the normalised form.

25-12-15 20:29:12:330 [ debug sync.syncjournalfilerecord ]	[ OCC::SyncJournalFileRecord::fromSqlQuery ]:	Restored from db: SyncJournalFileRecord(path: "ō_orig", inode: [inode(orig)], modtime: [modtime(orig)], type: CSyncEnums::ItemTypeFile, etag: "[etag(orig)]", fileId: "[spaceid]![fileid(orig)]", remotePerm: "WDNVR", size: [size(orig)], checksum: "SHA1:[SHA1(orig)]", serverHasIgnoredFiles: false, hasDirtyPlaceholder: false)
25-12-15 20:29:12:341 [ info sync.discovery ]:	Processing (db|local|remote) "ō_orig" | valid: true/false/true | mtime: [modtime(orig)]/0/[modtime(orig)] | size: [size(orig)]/0/[size(orig)] | etag: "[etag(orig)]"//"[etag(orig)]" | checksum: "SHA1:[SHA1(orig)]"//"SHA1:[SHA1(orig)]" | perm: "WDNVR"//"WDNVR" | fileid: "[spaceid]![fileid(orig)]"//"[spaceid]![fileid(orig)]" | inode: [inode(orig)]/0/ | type: CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeUnsupported/CSyncEnums::ItemTypeFile
25-12-15 20:29:12:341 [ info sync.discovery ]:	Discovered "ō_orig" CSyncEnums::CSYNC_INSTRUCTION_REMOVE OCC::SyncFileItem::Up CSyncEnums::ItemTypeFile
25-12-15 20:29:12:341 [ info sync.discovery ]:	Processing (db|local|remote) "ō_mod" | valid: false/true/false | mtime: 0/[modtime(orig)]/0 | size: 0/[size(orig)]/0 | etag: ""//"" | checksum: ""//"" | perm: ""//"" | fileid: ""//"" | inode: 0/[inode(orig)]/ | type: CSyncEnums::ItemTypeUnsupported/CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeFile
25-12-15 20:29:12:341 [ debug sync.syncjournalfilerecord ]	[ OCC::SyncJournalFileRecord::fromSqlQuery ]:	Restored from db: SyncJournalFileRecord(path: "ō_orig", inode: [inode(orig)], modtime: [modtime(orig)], type: CSyncEnums::ItemTypeFile, etag: "[etag(orig)]", fileId: "[spaceid]![fileid(orig)]", remotePerm: "WDNVR", size: [size(orig)], checksum: "SHA1:[SHA1(orig)]", serverHasIgnoredFiles: false, hasDirtyPlaceholder: false)
25-12-15 20:29:12:341 [ info sync.discovery ]:	Not a move, base file still exists at "ō_orig"

[TheOneRing]

@l33 which client and server version are you using?

[l33]

It's server version 4 (image 72c2298b0a77) and client version 3.0.2.2006 67f373.

[micbar]

@l33 Are you using samba storage? This is not supported in OpenCloud.

[l33]

No, this is on an ext4 local file system. The samba server was running on the same machine where OpenCloud is now running but it has been turned off since OpenCloud is used.