Files 'corrupted' with non-existent lock xml?

Hi All a new Nextcloud user here. I’ve got Nextcloud setup on a freshly installed Ubuntu server:
Nextcloud version: 19.0.0
Operating system and version : Ubuntu 20.04
nginx version: nginx/1.18.0 (Ubuntu)
PHP version: 7.4.3

What I have done is:

  1. Create the server above and create a single user ‘james’

  2. Install Windows 10 desktop sync client (v2.6.5) on my desktop machine, start with empty sync directory. This will be the ‘master’ (source) of files.

  3. Install Windows 10 desktop sync client (v2.6.5) on my laptop machine, start with empty sync directory.

  4. Fairly slowly move ~30GB of data into the desktop sync directory (I was reorganising it), this is basically my personal file store, lots of small files / code / documents.

  5. Once the file move was complete and both the laptop and desktop were synced, to check the sync I used Beyond Compare to binary compare the desktop and laptop files.

What I see on the laptop, which has synced down from the server, is some files that although they are the same size and file modification date they have xml replacing the start of the file like so:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>OCA\DAV\Connector\Sabre\Exception\FileLocked</s:exception>
  <s:message>"Projects" is locked, existing lock on file: none</s:message>
</d:error>

Now the files on the desktop machine are OK, and it looks like they have made it to the server file store OK but the laptop has these “corrupted” files?

I’ve been reading around to try and understand what’s happening here but I can’t figure it out - can someone explain what’s going on -why it is happening and how can I fix it? Or any pointers of where to look further?

It is strange that the error message is saying existing lock on file: none

Many thanks!

Does anyone have any thoughts on this? Presumably Nextcloud shouldn’t be corrupting files like this, or is this expected behaviour?

I have now completed a full memtest86 on all three machines and all are clean, so it’s not dodgy RAM.