I had to deactivate the (defaultly activated) VirtualFiles feature on my Windows 10 system NextCloud Client. This was necessary so that I would be able to work without popping-up download windows on my system with enough storage memory.
Unfortunately, files which are updated from other clients within the system (there are several Linux Clients within the system) now cause synchronisation conflicts on my Windows system (the one where I deactivated VirtualFiles).
So, on my Windows system, I see the yellow conflict icon within the client, and when I look up the respective folder, I see respective conflict files like this one:
_status (conflicted copy 2022-03-10 050117).ini
After removing the conflict files (which have the same size as the original files) the local client enters normal operation, again.
How could I clean the system to not always create these conflict files, as, obviously, there are no conflicts.
Why do you have Linux Clients on your Windows machine?
You don’t sync the same folder with different sync clients? The conflict files originate from local changes done when the file on the server changed as well, then a local conflict file is preserved to not overwrite some other change of the file. If other clients change things of a file (it might be just a quick renaming back and forth, a change in modification date etc.) this might trigger the Nextcloud client about “changes” and consider them as conflicting.
Sorry. Wrong wording. On my “main” computer, I use a Windows 10 operating system. Here, I have a NextCloud Client installed to access a remote NextCloud Server (the server is running on a Debian Linux system). In addition to my single Windows-NextCloud-Client, there are several Linux-NextCloud-Clients connected to the same Server instance. On each machine within my overall NextCloud system, there is in every case definitely only one local NextCloud client application involved.
The file _status.txt I mentioned in my first post, is a text file which might get read on the Windows system. But never gets changed, here. It is a file that gets updated every day at 5:00 am by one of the Linux clients. This is done for more than 2 years, now. And it worked perfectly without any synchronisation conflicts…
Until I manually switched my Windows client behavior (back) from VirtualFiles mode to Non-VirtualFiles mode, some days ago. As soon as I switched off the VirtualFiles mode, synchronization issues like the one described are visible on my Windows client system. For those files which were updated on other clients.
So I thought, the switching-off of VirtualFiles might have caused something more. Something which somehow renders my files on the Windows client system as if they have been changed locally. But they haven’t.
Recently, there were quite a few changes to the client. However, I’m not at all in on all the details and what might influence it. I’d try to see to get some logfiles, if you can spot any problem and perhaps relate it to some existing github issue. If not, try to create your own.
On the windows client, I’d check if _* files are not on the ignored files list. Can you trigger this behavior with other files changed by a different client or via web-interface?