Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Unexpected PDF duplicates in group folders #6549

Open
5 of 8 tasks
Rudiberto opened this issue Mar 15, 2024 · 12 comments
Open
5 of 8 tasks

[Bug]: Unexpected PDF duplicates in group folders #6549

Rudiberto opened this issue Mar 15, 2024 · 12 comments

Comments

@Rudiberto
Copy link

Rudiberto commented Mar 15, 2024

⚠️ This issue respects the following points: ⚠️

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?

  • 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
Copy link
Member

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?

@joshtrichards joshtrichards transferred this issue from nextcloud/server Mar 16, 2024
@Rudiberto
Copy link
Author

Rudiberto commented Mar 16, 2024

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
Copy link

Freshou commented Mar 18, 2024

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...

nextcloud/server#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
Copy link
Author

Rudiberto commented Mar 21, 2024

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
Copy link

zbynekslozil commented Mar 22, 2024

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
Copy link
Author

Rudiberto commented Mar 22, 2024

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
Copy link

zbynekslozil commented Mar 24, 2024

This commit? e5c7965

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
Copy link
Author

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
Copy link

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
Copy link

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

camilasan added a commit that referenced this issue May 24, 2024
Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue May 24, 2024
Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since since it was hitting "Move without permission to rename base file"
- The files was then procesed as a new file

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since since it was hitting "Move without permission to rename base file"
- The files was then processed as a new file

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since since it was hitting "Move without permission to rename base file"
- The file was then processed as a new file

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since since it was hitting "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 5, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 24, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 25, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jun 25, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
camilasan added a commit that referenced this issue Jul 5, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
backportbot bot pushed a commit that referenced this issue Jul 5, 2024
- The rename check was not happening since it was hitting error "Move without permission to rename base file"
- The file was then processed as a new file
- Also check #6535.

Possible workaround for #6549.

Signed-off-by: Camila Ayres <[email protected]>
@joshtrichards
Copy link
Member

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

@zbynekslozil
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants