Server: Critical: renaming files inside shared nested folder duplicates file

Created on 21 Jun 2018  路  10Comments  路  Source: nextcloud/server

Precondition:

Users U, S1 and S2 must have desktop sync client installed (Ubuntu) and configured to share all remote files/folders.

Steps to reproduce

  1. User U creates a folder A
  2. User U creates a folder B inside A
  3. User U shares folder A with users S1 and S2
  4. User U shares folder B with users S1 and S2
  5. User U creates a file F in folder B (in desktop)
  6. Wait until all users' desktop sync clients finish sync those files and folders
  7. User U renames file F to F2
  8. Wait until all users' desktop sync clients finish syncing the files

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

Enabled:
  - comments: 1.3.0
  - dav: 1.4.7
  - federatedfilesharing: 1.3.1
  - federation: 1.3.0
  - files: 1.8.0
  - files_sharing: 1.5.0
  - files_trashbin: 1.3.0
  - files_versions: 1.6.0
  - lookup_server_connector: 1.1.0
  - oauth2: 1.1.1
  - provisioning_api: 1.3.0
  - sharebymail: 1.3.0
  - systemtags: 1.3.0
  - theming: 1.4.5
  - twofactor_backupcodes: 1.2.3
  - updatenotification: 1.3.0
  - workflowengine: 1.3.0
Disabled:
  - admin_audit
  - encryption
  - files_external
  - testing
  - user_ldap

Nextcloud configuration:


Config report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "http:\/\/localhost\/nc13_stable",
        "dbtype": "mysql",
        "version": "13.0.4.0",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true
    }
}

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.

0. Needs triage bug sharing

Most helpful comment

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.

  • If it's not the case, A is shown normally in root (/). _(This is how it works in NC today)_

  • If it's the case (i.e: A is also available to the user through one of its parent folder F), we compare the user's permissions to the direct share A and the permissions given through F:

    • If the user has higher permissions to the direct share A compared to the shared parent folder F, then A will be shown in root, and therefore will be duplicated. _(This is also how it works in NC today)_

    • If the user has lower or same permissions to the direct share A compared to the shared parent folder F, then A _won't be shown_ in root (/). In other words, it won't be duplicated. _(This changes NC's behavior: today, NC always duplicates A in root)_

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 lib/private/Files/View.php, but we know that it should be in lib/private/Share/Share.php. The query we've created gets a list of filecaches based on a list of fileids.

If you'd like to see it working, it's available in this commit: https://github.com/coletivoEITA/server/commit/7c619a33d450f927106a51db095ef1e20e4e145f

Is it of interest? If so, we can change the implementation to have the query inside Share.php

All 10 comments

GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/6491 (Duplicate Shared folders), https://github.com/nextcloud/server/issues/8628 (renaming shared folder - no actualization), https://github.com/nextcloud/server/issues/553 (Issues after renaming an already shared folder...), https://github.com/nextcloud/server/issues/9152 (Problem renaming folders), and https://github.com/nextcloud/server/issues/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 -> https://github.com/nextcloud/server/issues/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.

  • If it's not the case, A is shown normally in root (/). _(This is how it works in NC today)_

  • If it's the case (i.e: A is also available to the user through one of its parent folder F), we compare the user's permissions to the direct share A and the permissions given through F:

    • If the user has higher permissions to the direct share A compared to the shared parent folder F, then A will be shown in root, and therefore will be duplicated. _(This is also how it works in NC today)_

    • If the user has lower or same permissions to the direct share A compared to the shared parent folder F, then A _won't be shown_ in root (/). In other words, it won't be duplicated. _(This changes NC's behavior: today, NC always duplicates A in root)_

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 lib/private/Files/View.php, but we know that it should be in lib/private/Share/Share.php. The query we've created gets a list of filecaches based on a list of fileids.

If you'd like to see it working, it's available in this commit: https://github.com/coletivoEITA/server/commit/7c619a33d450f927106a51db095ef1e20e4e145f

Is it of interest? If so, we can change the implementation to have the query inside Share.php

Sharing process in nextcloud is too complicated, unintuitive and dangerous for data. Why it can't be normal like in Windows?
/nextcloud_server1/user/dir
/nextcloud_server2/user/dir
It's the most intuitive and understandable by most non technical people.
It should be completely redesigned.

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

Was this page helpful?
0 / 5 - 0 ratings