-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Critical: renaming files inside shared nested folder duplicates file #9957
Comments
GitMate.io thinks possibly related issues are #6491 (Duplicate Shared folders), #8628 (renaming shared folder - no actualization), #553 (Issues after renaming an already shared folder...), #9152 (Problem renaming folders), and #3502 (Duplicated files and folders when moving from one shared folder to another (can reproduce it)). |
I think, it can be connected with my issue -> #8301 |
We have a proposal to deal with this issue. If there is interest in the community, we can propose a Pull Request. Briefly, the proposal is as follows: When preparing the list of files/folders to be shown to the user in root (/), we check if there is a direct share A that is also shared to the same user through a parent shared folder F.
We have a working implementation of this solution, but we know we should change the Share Class for correctly querying the database: we've temporarily created a query in the view If you'd like to see it working, it's available in this commit: coletivoEITA@7c619a3 Is it of interest? If so, we can change the implementation to have the query inside |
Sharing process in nextcloud is too complicated, unintuitive and dangerous for data. Why it can't be normal like in Windows? |
cc @nextcloud/sharing |
@pawlosck the sharing model Nextcloud uses is the same as in Dropbox, Google Drive and OneDrive and they use that simpler model because it is easier to understand and deal with than having these expansive user directories that were invented in the '90's. Of course, people who are still used to those find the 'new' model weird and complicated, a classic example of how you can never make everybody happy I guess. Meanwhile, I do like the idea of @dtygel as it allows users to 'upgrade' the share permissions without getting duplicate shares. @jancborchardt what do you think, is this the right approach? |
@jancborchardt @nextcloud/sharing given @dtygel is willing to do a PR we should really give some thinking to this... Of course, I understand everybody is focusing on finishing and releasing Nextcloud 14 now. @dtygel you coming to the Nextcloud conference? |
hi @jospoortvliet , I worked in pair with @dtygel in this patch. We are from a cooperative in Brazil (eita.coop.br) and one of our main products is a Nextcloud-based solution, that we would like to present in the conference. We have interest in participating and would like to apply for the 80% support for travel and accommodations. |
Well a PR is welcome of course. With code it is easier to discuss but my fear is mainly that this reduces scalability a lot. As you need to traverse up for all shares. And we have customers that have close to 1.5k shares for a single user. But as said. Please submit a PR and we can have a look and discuss. |
As the version of the software you've reported this for has reached end of life, I will close this ticket. If this is still happening after an upgrade to the latest version, feel free to reopen |
Est-ce que le bug pourrait être dans le NextCloud Client Mac avec une erreur d'interprétation des Groups Folder ?!?!? Mais quand je demande l'archive de déboggage du NextCloud Client j'ai ceci au moment ou j'effectue le rennommage : 2024-03-18 15:05:35:840 [ info nextcloud.sync.discovery /var/folders/yr/9dx0mtfj7kdf4725tmcz6md80000gp/T/macos-21208/src/libsync/discovery.cpp:474 ]: Processing "0300 - LAS Comptabilité/test David--.pdf" | (db/local/remote) | valid: true/false/true | mtime: 1707760237/0/1707760237 | size: 84331/0/84331 | etag: "2edf741481fbeb2075128501b8d84055"//"2edf741481fbeb2075128501b8d84055" | checksum: "MD5:337154430db00d63039a72c3f86e2ec2"//"" | perm: "WDNVRM"//"WDNVRm" | fileid: "37574027oc98lfxeupo5"//"37574027oc98lfxeupo5" | type: CSyncEnums::ItemTypeFile/CSyncEnums::ItemTypeSkip/CSyncEnums::ItemTypeFile | e2ee: false/false | e2eeMangledName: ""/"" | file lock: not locked//not locked | file lock type: ""//"0" | metadata missing: /false/ |
Les lignes suspectes sont : `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"` Selon moi ! |
Precondition:
Users U, S1 and S2 must have desktop sync client installed (Ubuntu) and configured to share all remote files/folders.
Steps to reproduce
Expected behaviour
All users should see a file named F2 in folder B.
Actual behaviour
All users (U, S1 and S2) see both files F and F2 in folder B.
Server configuration
Operating system: Ubuntu 18.04
Web server: Apache2
Database: Mysql
PHP version: 7
Nextcloud version: 13 (from branch stable13)
Updated from an older Nextcloud/ownCloud or fresh install: Fresh install
Where did you install Nextcloud from: Github
Signing status:
Signing status
`integrity checker has been disabled. Integrity cannot be verified`List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: No
Are you using encryption: No
Are you using an external user-backend, if yes which one: No
Client configuration
Browser: Firefox
Operating system: Ubuntu 18.
The text was updated successfully, but these errors were encountered: