multiple synchronization conflicts after deactivation of VirtualFiles

[nnako]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

a bit of history

Some day in 2021, my NextCloud Client started to show popup windows about "downloading file ..." whenever I clicked on a locally, newly synchronized file within the file explorer. I was told that this behavior was due to a new feature called "Virtual Files", especially designed for client computers with low storage capacity compared to the NextCloud storage size.

As I have plenty of local storage space (and just a small NextCloud size) and at the same time wanted to overcome the drawback of Virtual Files that file-based backups of NextCloud folders don't really seem to work, I decided to deactivate the Virtual Files feature on my Windows computer.

After doing so, it seemed to me that all the files were finally downloaded and the popup window never showed up again. But, with deactivation of Virtual Files, immediately another problem arouse which I want to describe here.

Expected behaviour

When I update single files (e.g. _status.ini) on one of the other (remote) NextCloud clients, I want these files to be just synchronized with the server and with my Windows client. Showing no conflict files if I haven't touched the file that was updated on the other client.

Actual behaviour

When I update single files (e.g. _status.ini) on one of the other (remote) NextCloud clients, those files seem to cause a conflict on my local Windows client, even though I have not touched them within the Windows system, actively. The behavior is as if I had (parallel to the update on the other client) updated the same file on my local Windows system:

There appears to be the (correct) file version which came synchronized from the NextCloud server but also a Windows-local conflict file, having the same file size as the synchronized one but an older creation date:

Steps to reproduce

1. change a file on a remote client
2. wait for the change to be synchronized
3. see the conflict file appear on the Windows client (where the Virtual Files were disabled)

Client configuration

Client version: 3.4.1

Operating system: windows-10.0.18363

OS language: German

Installation path of client: C:\Program Files\Nextcloud\nextcloud.exe

Server configuration

Nextcloud version: 23.0.2.1

Storage backend (external storage): ?

Logs

Client logfile:

https://gist.github.com/nnako/42e98264885f79247473b2844ad034ac

Description of the log file:

• the logfile was about 90 MB of size, so I just kept the lines where the file names appeared together with ther immediate surroundings
• marked in RED are the findings related to a PDF file which was created / updated on a remote client
• marked in DARK BLUE are the findings related to a textfile which was updated (it will be updated every day at about 5 am) on another remote client
• marked in light green are the findings related to a textfile which was not updated externally but resides within the same folder as the latter changed text file.

[nnako]

just an addition to the issue description above...

as the _status.ini file is updated / written each day at about 5am by a Linux client, I get the synchronization conflict notification together with the conflict file _status (conflicted copy <date>).ini each time I switch on my Windows machine in the morning.

the conflict file is dated always to the day before, 5:01am (so, short time after the update from the Linux client). as if the local Windows client changed the _status.ini file as soon as it sees the synchronized file, but somehow thinks, it changed before the sync... but the local Windows client didn't change it at all.

strange.

[nnako]

and another addition to the issue description above...

over the days, the locally collected conflict files on the Windows client get more and more, even though definitely no change (not even a read operation) was performed on the _status.ini file from the Windows client. the list shows:

_status.ini
_status (conflicted copy 2022-03-18 050115).ini
_status (conflicted copy 2022-03-19 050112).ini
_status (conflicted copy 2022-03-20 050152).ini
_status (conflicted copy 2022-03-21 050150).ini
_status (conflicted copy 2022-03-22 050134).ini

the _status.ini file is still updated / written each day at about 5am by a Linux client

any ideas?

[nnako]

now, the issue seems to have disappeared, as the last conflicted copy appeared on 27th (three days ago):

_status.ini
_status (conflicted copy 2022-03-18 050115).ini
_status (conflicted copy 2022-03-19 050112).ini
_status (conflicted copy 2022-03-20 050152).ini
_status (conflicted copy 2022-03-21 050150).ini
_status (conflicted copy 2022-03-22 050134).ini
_status (conflicted copy 2022-03-23 050049).ini
_status (conflicted copy 2022-03-24 050101).ini
_status (conflicted copy 2022-03-25 050051).ini
_status (conflicted copy 2022-03-26 050056).ini
_status (conflicted copy 2022-03-27 050115).ini

As neither my Windows version nor my NextCloud Client version changed, I assume there has been a NextCloud Server version update to v23.0.2.1 in the mean time which solved the issue.

The server release page says the release was available "5 days ago". Assuming that there is a certain delay, the update could have caused the solution of my issue. Unfortunately, I can't identify any hint within the commit messages...

Can anybody see if this was possible? Could the update have caused a solution to my problem?

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[github-actions]

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!