⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

WebDAV clients can request information about files and sub-folders in (at least) two different ways:

1. by requesting a list of all items in a folder
   PROPFIND /remote.php/webdav/my_folder/
   (notice the tailing dash in the request)
   returns a xml with one <d:response> section per item in the folder, each containing a <d:displayname> attribute
2. by requesting properties of each item in the folder seperatly
   PROPFIND /remote.php/webdav/my_folder/my_subfolder
   (notice NO tailing dash in the request)
   returns a xml with only one <d:response> section for my_subfolder, containing a <d:displayname> attribute

Both xmls will have a <d:response> section for my_subfolder, however in certain circumstances their <d:displayname> attribute is not equal (see steps to reproduce)

I believe response 1 is the intended and correct response (as it matches up with the contents of the <d:href> attribute) and response 2 is a bug.

Steps to reproduce

Use web interface:

1. as user_A create a folder my_folder_A
2. as user_A share my_folder_A with user_B
3. as user_B rename my_folder_A to my_folder_B
   Now depending on which account you are using the same folder content is accessible by two different path. So far behaviour as expected.

Use a WebDAV client (e.g. Nemo on a Linux Mint machine) and observe the network requests:
4. with the credentials of user_B request the base directory
4.1. PROPFIND /remote.php/webdav/ is sent
4.2. receives the xml including <d:response> section for the shared folder with a <d:displayname> attribute of "my_folder_B"
This matches up with the tail of the <d:href> attribute and the way the folder name is displayed in the web interface.
4.3. "my_folder_B" is displayed in the Nemo GUI
4.4. Nemo immediately goes on requesting properties of each item in the base directory with an individual request for each one. E.g. PROPFIND /remote.php/webdav/my_folder_B
[N.B.: I don't see a particular benefit in this behaviour of Nemo as it seems to gain no information by this step, that are not already discovered with step 4.1, but technically there is nothing wrong with these requests]
4.5 receives the xml only containing the <d:response> section for the shared folder with a <d:displayname> attribute of "my_folder_A"
This does NOT match up with the tail of the <d:href> attribute and the way the folder name is displayed in the web interface.
4.6 Nemo changes the displayed name in the GUI from "my_folder_B" to "my_folder_A"

Expected behavior

<d:displayname> attribute of step 4.2 and 4.5 should at least be equal, probably matching up the the <d:href> tail.

Installation method

Community Manual installation with Archive

Nextcloud Server version

25

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

None

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

No response

List of activated Apps

- activity: 2.17.0
  - admin_audit: 1.15.0
  - bruteforcesettings: 2.5.0
  - calendar: 4.3.1
  - circles: 25.0.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contacts: 5.2.0
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - gpxedit: 0.0.14
  - impersonate: 1.12.0
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - mail: 2.2.5
  - notifications: 2.13.1
  - oauth2: 1.13.0
  - password_policy: 1.15.0
  - photos: 2.0.1
  - previewgenerator: 5.2.1
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - recommendations: 1.4.0
  - related_resources: 1.0.4
  - richdocuments: 7.1.2
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - spreed: 15.0.5
  - support: 1.8.0
  - systemtags: 1.15.0
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_admin: 4.1.9
  - twofactor_backupcodes: 1.14.0
  - twofactor_nextcloud_notification: 3.6.0
  - twofactor_totp: 7.0.0
  - twofactor_webauthn: 1.1.2
  - updatenotification: 1.15.0
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflow_script: 1.10.0
  - workflowengine: 2.7.0

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response