<file_target> of a auto-renamed file is not correct directly after sharing

[individual-it]

Steps to reproduce

1. create user "uu1" and "uu2"
2. login as both once to make sure a "welcome.txt" exists
3. from "uu2" share "welcome.txt" to "uu1"
4. query the sharing API curl -u uu2:uu2 http://localhost/owncloud-core/ocs/v1.php/apps/files_sharing/api/v1/shares

Expected behaviour

<file_target>/welcome (2).txt</file_target>

Actual behaviour

<file_target>/welcome.txt</file_target>

• after querying the sharing API from the side of "uu1" or reloading the page as "uu1" the API respond from "uu2" side gets corrected
• with user-key enabled encryption the result is correct immediately

I think the expectation in this acceptance tests is wrong:
https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharing/createShare.feature#L15

Server configuration

Operating system:
Ubuntu 18.04
Web server:
Apache 2
Database:
Sqlite
PHP version:
7.2
ownCloud version: (see ownCloud admin page)
10.1.0.1
Updated from an older ownCloud or fresh install:
fresh
Where did you install ownCloud from:
git

The content of config/config.php:

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost"
        ],
        "dbtype": "sqlite3",
        "version": "10.1.0.1",
        "logtimezone": "UTC",
        "instanceid": "oc2fs70i9byd",
        "loglevel": 2,
        "csrf.disabled": true,
        "datadirectory": "\/home\/artur\/www\/owncloud-core\/data",
        "overwrite.cli.url": "http:\/\/localhost\/owncloud-core",
        "htaccess.RewriteBase": "\/owncloud-core\/",
        "installed": true
    }
}

List of activated apps:

Enabled:
  - comments: 0.3.0
  - dav: 0.3.2
  - federatedfilesharing: 0.3.1
  - federation: 0.1.0
  - files: 1.5.1
  - files_external: 0.7.1
  - files_sharing: 0.10.1
  - files_texteditor: 2.2.1
  - files_trashbin: 0.9.1
  - files_versions: 1.3.0
  - notifications: 0.3.4
  - provisioning_api: 0.5.0
  - systemtags: 0.3.0
  - updatenotification: 0.2.1
Disabled:
  - encryption
  - enterprise_key
  - files_antivirus
  - files_primary_s3
  - firewall
  - guests
  - multidirtest
  - oauth2
  - testing
  - user_ldap
  - user_management

Are you using external storage, if yes which one: local/smb/sftp/...
no
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
no

Client configuration

Browser:
FF 61
Operating system:
Ubuntu 18.04

[ownclouders]

GitMate.io thinks possibly related issues are #2822 (By renaming a shared file is not shared any more), #4028 (Renaming not possible for directly shared files/folders), #8558 (Shared Files Renaming), #6197 (Rename after share doesn't rename the file in Shared dir), and #28218 (Renaming shared file issue ).

[PVince81]

This sounds vaguely familiar. It is possible that the encryption code is doing some setupFS() stuff during that process which would pre-initialize the file_target while when there is no encryption, the setupFS() only happens later on access.

I seem to remember observing this in the past while writing encryption related tests.

[PVince81]

Ah, here it is: #26844 (comment)

Explanation here: #26844 (comment)

However it is not clear to me how the problem managed to disappear back then.

[PVince81]

Now thinking of it, in that PR the observation was based on test side effects where some files from another test were still here.

It is possible that we haven't had a test for a deliberate duplicate so far, and the inconsistency still exists.

In general I'm not sure if we can prevent the setupFS() from encryption. What we could do for consistency is also add a setupFS() related code paths for the non-encrypted code paths to make the behavior consistent.