-
Notifications
You must be signed in to change notification settings - Fork 803
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
Comments
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? |
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. |
Got same kind of problem with Desktop client on a Mac ... But when duplicating file ... 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"` |
Two things I just figured out
|
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). |
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. |
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. |
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. |
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. |
Maybe @allexzander can look at it. Changes are from #6264 (backport #6268). |
Possible workaround for #6549. Signed-off-by: Camila Ayres <[email protected]>
Possible workaround for #6549. Signed-off-by: Camila Ayres <[email protected]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
- 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]>
#6780 released in v3.13.2 includes a possible fix for this. Anyone using v3.13.2 still see this behavior? |
I am not catching any problem with v3.13.2 client and v28.0.8 server now. |
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
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?
Configuration report
Can't do that - hosted server
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
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
The text was updated successfully, but these errors were encountered: