3.4.2 conflicts on every edit

[ColinFinck]

I was affected by #4016, and as a result of that, I've updated all clients on all machines to 3.4.2, updated the server from 22.0.0 -> 22.1.1 -> 22.2.3 -> 23.0.0 -> 23.0.1, and followed https://github.com/nextcloud/desktop/wiki/Fix-bug-invalid-modification-date to fix the invalid modification dates on the server.

Unfortunately, I'm now affected by an even more severe bug:

Steps to reproduce

1. I create a new file "test.txt" and write a single letter "a" into it, and hit Ctrl+S to save. I even wait until the Nextcloud client shows it is synchronized.
2. With the editor still open, I add a second letter "b" and hit Ctrl+S again.
3. The Nextcloud client shows "Conflict: Server version downloaded, local copy renamed and not uploaded", I get a "test (conflicted copy 2022-02-03 084856).txt", and Nextcloud asks me what version to keep.
   Even worse, Nextcloud first overwrites my just edited version of the file by the server copy (which only contains "a"). My editor notices that and asks me whether to reload the file. If I hit "Yes", my latest edit is gone.

This is perfectly reproducible on two Windows 10.0.19044 systems (connected to the same Nextcloud account).
I'm using a traditional setup with a single Nextcloud folder that is locally synchronized (no virtual folders).

Expected behaviour

Nextcloud uploads the newly edited file without a notice, as it did for years.

Actual behaviour

Nextcloud replaces my edits with the last copy from the server and asks for conflict resolution, making work inside the Nextcloud folder impossible.

Client configuration

Client version: 3.4.2
Operating system: Windows 10 (10.0.19044)
OS language: German
Installation path of client: C:\Program Files\Nextcloud

Server configuration

Nextcloud version: 23.0.1
Storage backend (external storage): local

[sagitariozod]

Hello.

I have the same problem.

I hope it is resolved quickly, it is not comfortable to work with this error.

Greetings.

[sagitariozod]

As a temporary solution I have installed the client version 3.4.0-RC1 (3.3.81) and it does not have this bug.

All versions higher than this have the bug.

Greetings.

[jospoortvliet]

I can reproduce this, but only in a folder that is shared with other people. It might simply not happen on a file that is not shared?

Steps were similar:

• create a file, add a line of text
• save in a shared folder
• wait until the green tick shows up (file is synced)
• add another line of text and hit save
• wait for sync - conflict file shows up, your editor warns your file was changed.

Debug archive created, accessible to the engineers: https://cloud.nextcloud.com/f/5575442

[mgallien]

so this is a bug of bulk upload
people with the ability to reproduce the bug, could you share your logs with me ?
I think I have the time to give this a look quickly

[sagitariozod]

At this moment I can't send the debug file, but I confirm that it happens in shared and unshared folders.

Greetings.

[balvie]

I have a situation here as mentioned in:
3.4.0 keep synchronizing files after upgrade

Went back to 3.3.6 in order to wait for the "storm"to pass. After seeing 3.4.2 available I was lured to update the client.
No I am trying to solve it issues with the aid of:
https://github.com/nextcloud/desktop/wiki/Fix-bug-invalid-modification-date
I've encountered some problems as the environment in which the mentioned scripts are not defined. Looking for solutions I came here and want to offer my help as test case ( and rubber duck).
I use client 3.4.2 on win10? and server 23.0.0.
Where and how can I help
I made a backup of the nd data directory and put the server in maintenance mode.

[ColinFinck]

I see that @jospoortvliet has posted a debug archive. Is there anything else you need from me as the original reporter?
I'm here to help, but I had a look into my debug archive and it contains a lot of personal data. Hence, it would be good to know what you're looking for exactly.

[mgallien]

@ColinFinck that should be fine, thanks and sorry for the troubles
in case I would need feedback to confirm the problem is solved, are you able to test with a specific version I would provide ?

[sagitariozod]

Hello @mgallien, I could test the specific version you mention.

If you want you can send it to me.

Greetings.

[mgallien]

@ColinFinck @jospoortvliet @sagitariozod applying this pull request to my server v23 nextcloud/server#30999 is enough to fix the issue for me

[mgallien]

sorry for the delay analyzing this issue

[ColinFinck]

@mgallien I have just applied nextcloud/server#30999 to my Nextcloud 23.0.1 instance, but unfortunately it doesn't fix the problem for me.
I still get a conflict every time I edit an existing file again.

[mgallien]

@ColinFinck I will need your logs
I could no longer reproduce the conflicts after applying the server patch

[sagitariozod]

I have replaced on server the file OC_Helper.php but the problem still persist.

[mgallien]

I have replaced on server the file OC_Helper.php but the problem still persist.

@sagitariozod I am not sure what you did but in any case I cannot dig further without logs of the desktop client

[sagitariozod]

@mgallien en teoría estaba aplicando el parche

@mgallien I have just applied nextcloud/server#30999 to my Nextcloud 23.0.1 instance, but unfortunately it doesn't fix the problem for me. I still get a conflict every time I edit an existing file again.

@mgallien in theory I was applying the patch that you indicated, not if what I have done is correct.

I'll send you the desktop client logs as soon as I can find time to sanitize them and remove sensitive information.

Apologies for my English, I use the google translator.

Greetings.

[ColinFinck]

@ColinFinck I will need your logs I could no longer reproduce the conflicts after applying the server patch

I created a new user for that on my Nextcloud server and installed Nextcloud Desktop 3.4.2 on a Windows 10 machine that didn't have any exposure to Nextcloud before. I could again reproduce the problem.
Here are the redacted and combined logs: https://gist.github.com/ColinFinck/c0dca5d36bf83d5ae90558adf47c9f1f

[mgallien]

@mgallien en teoría estaba aplicando el parche

@mgallien I have just applied nextcloud/server#30999 to my Nextcloud 23.0.1 instance, but unfortunately it doesn't fix the problem for me. I still get a conflict every time I edit an existing file again.

@mgallien in theory I was applying the patch that you indicated, not if what I have done is correct.

I'll send you the desktop client logs as soon as I can find time to sanitize them and remove sensitive information.

Apologies for my English, I use the google translator.

Greetings.

What I was trying to say is that I really need the logs because without them I am afraid I cannot fix the bug.
Indeed, the exact steps you did is also very important because that may enable to more easily understand the problem

no problem for the communication and please apologize any troubles I am also not an English native speaker

[solracsf]

@mgallien can you please confirm that https://gist.githubusercontent.com/ColinFinck/c0dca5d36bf83d5ae90558adf47c9f1f/raw/499c8269083e268ca35361290f84251afaa4f47b/nextcloud-desktop-4243-logs-redacted-combined.txt has enough information to debug this?

[rwese]

I can report the same issue on linux as well, with the latest release 3.4.2, Server-Version: 23.0.1, later I will provide a debug log.

[PVince81]

I'm on 3.4.2 (openSUSE Tumbleweed) with NC 23.0.1 since today and the text files I edit often (local notes) are now having many conflicts.
I was not affected by the mtime issue, there are no negative entries in my oc_filecache.

I'll try and provide logs as well.

[DataGhost]

I can confirm I'm having the same issue and could reproduce the case in the issue description. My client hasn't been updated for two months so that probably can't be it. For me this started happening after upgrading server from 23.0.0 to 23.0.1 about two weeks ago. The folder I'm syncing into is not a shared folder.

Server: 23.0.1 (Gentoo) with redis
Storage: 6x4TB 7200rpm in raidZ2
Client: 3.4.0 (Windows 10 20H2)
Connection: LAN gigabit

[poiNt3D]

I have just updated from version 22.something to 23.0.1 and installed windows client for the first time.
I am experiencing the same issue.

[nicokaiser]

The patch in nextcloud/server#30999 does not fix this, this patch only seems to deal with shared storage. The bug happens on normal non-shared folders on a standard installation (nextcloud/docker image on a Debian host, recent macOS client). I hope I'll find the time to create debug logs on the weekend.

[ColinFinck]

With that latest information, this sounds more like a bug in Nextcloud Server 23.0.1 than the sync clients, and should be escalated to that team.

@nickvergessen @PVince81 @skjnldsv Are you aware that latest Nextcloud 23.0.1 is apparently seriously broken with regard to basic file synchronization?

[mgallien]

The patch in nextcloud/server#30999 does not fix this, this patch only seems to deal with shared storage. The bug happens on normal non-shared folders on a standard installation (nextcloud/docker image on a Debian host, recent macOS client). I hope I'll find the time to create debug logs on the weekend.

I am working on this and I can reproduce it also with non shared folders
not yet an idea about which condition is enough to trigger the bug

[mgallien]

I'm on 3.4.2 (openSUSE Tumbleweed) with NC 23.0.1 since today and the text files I edit often (local notes) are now having many conflicts. I was not affected by the mtime issue, there are no negative entries in my oc_filecache.

I'll try and provide logs as well.

as far as I can tell the returned etag from bulk upload post request is not the one stored in oc_filecache table
that will confuse the desktop client and generate fake conflicts

[KimmoJ]

Honestly, every client over 3.3.6 is extremely suspect. I'm glad I'm the only user on my Nextcloud - Nextcloud needs a setting to hard set what users can install, client-wise, so one can prevent third parties from upgrading to these busted variants. I'm not budging off 3.3.6 until these error posts stop flooding in for 3.4.0, 3.4.1 and now 3.4.2. Try downgrading the client, that may let you work with some peace of mind.

[nerdling]

Honestly, every client over 3.3.6 is extremely suspect.

If it's a bad etag from the server for file batching, not sure what a client can really do about it apart from completely avoiding that feature.

[PVince81]

if it's the bulk upload plugin, one can disable it by commenting out https://github.com/nextcloud/server/blob/v23.0.0/apps/dav/lib/Capabilities.php#L32

I'll test this on my instance

[PVince81]

(also need to restart the client perhaps)

[DominikWA]

if it's the bulk upload plugin, one can disable it by commenting out https://github.com/nextcloud/server/blob/v23.0.0/apps/dav/lib/Capabilities.php#L32

I'll test this on my instance

I have exact the same problem in multiple instances.

This worked for me in my test instance.

Since this only deactivates a feature, it is save to also implement the workaround in productive instances?

[PVince81]

Since this only deactivates a feature, it is save to also implement the workaround in productive instances?

@DominikWA yes. the bulk upload was a new feature to improve upload performance. when disabled it falls back to the old approach

[DataGhost]

I can also confirm this has fixed the problem for me.

[ColinFinck]

Yes, disabling bulk upload on the server also fixes the problem for me. Thanks for the quick workaround!
I still hope that bulk upload eventually returns, as that was my original reason to upgrade to 23.x :)

[sagitariozod]

I confirm that disabling bulk upload on the server and restarting the clients fixes the problem.

Thank you very much for this solution.

[Treppengelaender]

if it's the bulk upload plugin, one can disable it by commenting out https://github.com/nextcloud/server/blob/v23.0.0/apps/dav/lib/Capabilities.php#L32

I'll test this on my instance

That seems to work for me on the Client 3.4.2 and 3.4.1 on two different Windows Machines. Running NC on Docker in Version 23.0.1.

But it does not look like this Bug does occur for Everybody, since this Thread is not very active for that kind of Error.

[sgoth]

But it does not look like this Bug does occur for Everybody, since this Thread is not very active for that kind of Error.

Well, there's this issue flagged as accepted. I for one currently don't have enough time to debug much further and have a workaround (downgrading client to 3.3.6). So actually not much reason to spam 'me too'. But it's true, not everyone on my instance has problems even though i do.

For what it's worth i'll try to provide some more info anyway:
I started to notice the issue only after triggering something that might be eligible for a 'bulk upload'.

I have a huge tree of markdown files like:

notes/big/tree
notes/archive/
[...]

After moving notes/big/tree to notes/archive locally and syncing it without issues, i started seeing the described behavior when editing any file under notes/.
But take that with a grain of salt...

[PVince81]

23.0.2 has been released with bulk upload disabled by default, so the problem will disappear for everyone for now until the underlying issue is debugged and fixed

[pbek]

For me NC 23.0.1 still worked with https://github.com/nextcloud/desktop/releases/tag/v3.4.0-rc2 and broke with 3.4.1.
I can confirm that there are no sync conflicts any more with the latest NC 23.0.2 (just updated the now available docker image) and the Desktop Client 3.4.2 on KDE Neon.