[Bug]: Unexpected PDF duplicates in group folders

[Rudiberto]

⚠️ This issue respects the following points: ⚠️

• [X] This is a bug, not a question or a configuration/webserver/proxy issue.
• [X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• [X] I agree to follow Nextcloud's Code of Conduct.

Bug description

Using a Windows OS, with virtual files, you are in a group folder. When exporting a PDF file in LibreOffice Writer without changing the original document name there are two files with the same name but different extensions. When we now change the name of the PDF file to another name and save the file with the new name, the new file appears and after counting to three the original file with the same name as the original writer document appears again. That works on and on, until you delete the PDF with the same name as the writer file.

Steps to reproduce

1. From an open LibreOffice Writer file export a PDF file
2. don't change the name, just let writer decide (doesn't matter if you change the folder, while you keep in the a group folder)
3. now change the name of the PDF file you just created to whatever you want and save it.
4. now wait three seconds and see the magic happen

Expected behavior

Expected behavior is, that a renamed file do not reappear.

Installation method

Community Web installer on a VPS or web space

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

don't know

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Updated from a MINOR version (ex. 22.1 to 22.2)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• [X] Default user-backend (database)
• [ ] LDAP/ Active Directory
• [ ] SSO - SAML
• [ ] Other

Configuration report

Can't do that - hosted server

List of activated Apps

Enabled:
  - activity: 2.19.0
  - calendar: 4.6.6
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - comments: 1.17.0
  - contacts: 5.5.3
  - contactsinteraction: 1.8.0
  - dashboard: 7.7.0
  - dav: 1.27.0
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_pdfviewer: 2.8.0
  - files_reminders: 1.0.0
  - files_rightclick: 1.6.0
  - files_sharing: 1.19.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - fileslibreofficeedit: 1.1.0
  - groupfolders: 15.3.5
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - mail: 3.5.7
  - notes: 4.9.2
  - notifications: 2.15.0
  - oauth2: 1.15.2
  - occweb: 0.1.1
  - password_policy: 1.17.0
  - photos: 2.3.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - sharebymail: 1.17.0
  - spreed: 17.1.6
  - systemtags: 1.17.0
  - tasks: 0.15.0
  - text: 3.8.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - updatenotification: 1.17.0
  - users_picker: 0.2.3
  - viewer: 2.1.0
  - workflowengine: 2.9.0
Disabled:
  - admin_audit: 1.17.0
  - bruteforcesettings: 2.7.0 (installed 2.4.0)
  - encryption: 2.15.0
  - files_external: 1.19.0
  - firstrunwizard: 2.16.0 (installed 2.11.0)
  - nextcloud_announcements: 1.16.0 (installed 1.14.0)
  - ransomware_protection: 1.14.0 (installed 1.14.0)
  - recommendations: 1.6.0 (installed 1.4.0)
  - richdocuments: 8.2.5 (installed 8.2.5)
  - richdocumentscode: 23.5.904 (installed 23.5.904)
  - support: 1.10.0 (installed 1.8.0)
  - survey_client: 1.15.0 (installed 1.10.0)
  - suspicious_login: 5.0.0
  - twofactor_totp: 9.0.0
  - user_ldap: 1.17.0
  - user_status: 1.7.0 (installed 1.5.0)
  - weather_status: 1.7.0 (installed 1.1.0)

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Hosted server

Additional info

I tried that on another installation with another provider and a similar app configuration, which shows the same behavior. Creating new folders in group folders also do not show a normal behavior: creating a new folder and giving it a new name, creates a new folder with the original name ("new folder") beside the recently renamed folder. Our employees are struggling a little bit, because of that. Because of the issue I updated from 27.1.7 to 28.03. So it exists also in 27.1.7

[joshtrichards]

This sounds like it's Desktop client sync related, so I'll move this over to that repository.

Are you only seeing this in Group Folders or standard folders as well?

[Rudiberto]

Group folders only, but our employees commented the same issue from different machines. All Windows, using virtual folders. And as I mentioned: I tried it on another installation also. Had to revoke Windows on my computer to test it.

[Freshou]

Got same kind of problem with Desktop client on a Mac ... But when duplicating file ... I was thinking it was with WorkSpace first, but they send me back to group folder...

https://github.com/nextcloud/server/issues/9957

After some research in the debug archive of the desktop client, I got those lines that I found out to be suspect...

`2024-03-18 15:05:35:840 [ warning nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:494 ]: File "0300 - LAS Comptabilité/test David--2.pdf" was modified before the last sync run and is not in the sync journal and server

2024-03-18 15:05:35:841 [ info nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:1388 ]: checking checksum of potential rename "0300 - LAS Comptabilité/test David--2.pdf" "MD5:337154430db00d63039a72c3f86e2ec2" "MD5:337154430db00d63039a72c3f86e2ec2"

2024-03-18 15:05:35:841 [ info nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:1435 ]: Move without permission to rename base file, source: true , target: true , targetNew: true , isExternalStorage: true

2024-03-18 15:05:35:841 [ info nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:1682 ]: "0300 - LAS Comptabilité/test David--2.pdf 8 1 0"

2024-03-18 15:05:35:841 [ info nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:1458 ]: Undid remove instruction on source "0300 - LAS Comptabilité/test David--.pdf"`

[Rudiberto]

Two things I just figured out

1. that it is the same on Linux, with no virtual folders. It only takes a little bit longer until the folder or the duplicate file appears. (up to 11 sec.)
2. that all files you are creating, after renaming, appear again as a duplicate with the former name! I tried that, because there was an update from 3.12.1 to 3.12.2 pending and I wanted to make sure that it is fixing the BUG. But it did not! I'm wondering if nobody else has this strange behaviour, but only us.

[zbynekslozil]

I think we have similar issue (at least it looks similar). When we create new folder in sub folder inside a group folder and it is renamed after synchronization, the folder is dupliceted (there is folder with old name and new name). I investigated other desktop versions and change is somewhere between version 3.10.1 and 3.10.2 . It hapens only with group folders (I tried windows and also linux).

[Rudiberto]

That is exactly what happens. You should be able to test the effect with any file you are creating with any name and then changing the name. Knowing now witch version causes the problem is a step further. I'm wondering why nobody else is suffering these problems.

[zbynekslozil]

This commit? https://github.com/nextcloud/desktop/commit/e5c79657723e1bb1fd1d69b455ef5ff29f73bffa

Group folders are connected as external storage. The conditions were changed in this commit and also output messages in code looks same as yours.

[Rudiberto]

I also thought that it is while syncing, but it's not the case. Was the first thing to try, waiting for synchronization, to see if it solves the problem.

[zbynekslozil]

It's really this commit. The problem with the duplicate directory will be solved if I revert the commit changes on the master. I tried it on a compiled version on linux.

[zbynekslozil]

Maybe @allexzander can look at it. Changes are from #6264 (backport #6268).

[joshtrichards]

#6780 released in v3.13.2 includes a possible fix for this. Anyone using v3.13.2 still see this behavior?

[zbynekslozil]

I am not catching any problem with v3.13.2 client and v28.0.8 server now.

[claucambra]

It seems like this issue is not happening any more so I will close. Thank you for reporting!