[Bug]: 32.0.5.0 (client 3.17.4) etag changes on unchanged file

⚠️ 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 OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I create a file and observe that the file has been uploaded to the server.
Shortly after I observe that the etag changes on that uploaded file.

2026-03-15 20:20:17

  : > nextcloud_stress_000.txt

2026-03-15 20:21:26

  curl --insecure --netrc --silent --show-error --fail -X PROPFIND -H 'Depth: 1' ${webdav_url}
    <d:response>
      <d:href>/nextcloud/remote.php/dav/files/bobw/Experiment/nextcloud_stress_000.txt</d:href>
      <d:propstat>
        <d:prop>
          <d:getlastmodified>Sun, 15 Mar 2026 20:21:03 GMT</d:getlastmodified>
          <d:getcontentlength>0</d:getcontentlength>
          <d:resourcetype/>
          <d:getetag>"88c99086c6d98de020ab8e2f8a09c5b9"</d:getetag>
          <d:getcontenttype>text/plain</d:getcontenttype>
        </d:prop>
        <d:status>HTTP/1.1 200 OK</d:status>
      </d:propstat>
    </d:response>

2026-03-15 20:21:35

    <d:response>
      <d:href>/nextcloud/remote.php/dav/files/bobw/Experiment/nextcloud_stress_000.txt</d:href>
      <d:propstat>
        <d:prop>
          <d:getlastmodified>Sun, 15 Mar 2026 20:20:17 GMT</d:getlastmodified>
          <d:getcontentlength>0</d:getcontentlength>
          <d:resourcetype/>
          <d:getetag>"57ff9ebccea81e6e04bc62d659d22d97"</d:getetag>
          <d:getcontenttype>text/plain</d:getcontenttype>
        </d:prop>
        <d:status>HTTP/1.1 200 OK</d:status>
      </d:propstat>
    </d:response>

Notice the change in etag:

  88c99086c6d98de020ab8e2f8a09c5b9
  57ff9ebccea81e6e04bc62d659d22d97

Steps to reproduce

1. Set up a Nextcloud Server (which emulates a remote connection with ~100ms delay)
2. Set up a Nextcloud Client and Add Folder Sync Connection to folder "Experiment" (not virtual)
3. Start a script loop containing "curl ... ${webdav_url}"
4. Create a file ( : > nextcloud_stress_000.txt )
5. Observe the upload to the server (from the curl script loop)
6. Observe the etag change on the server (from the curl script loop)

Standalone nextcloud environment for demonstrating issues.

Server:

sudo -u apache php -f /usr/share/nextcloud/console.php config:list system | grep version\.:
  "version": "32.0.5.0",

Client:

nextcloud --version
  Nextcloud version 3.17.4daily
  Git revision 371e4b9311e851dbb8d6ae6f7c3f77af958e1a33
  Using Qt 6.10.1, built against Qt 6.10.1
  Using Qt platform plugin 'xcb'
  Using 'OpenSSL 3.5.4 30 Sep 2025'
  Running on Fedora Linux 43 (Forty Three), x86_64

Expected behavior

one unique etag per unique file

Nextcloud Server version

32

Operating system

Other

PHP engine version

PHP 8.4

Web server

Apache (supported)

Database engine version

MariaDB

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

Fresh Nextcloud Server install

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

sudo -u apache php -f /usr/share/nextcloud/console.php config:list system | grep version\.:
  "version": "32.0.5.0",

List of activated Apps

Not relevant

Nextcloud Signing status

None relevant.

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- suspicious_login
	- INVALID_HASH
		- vendor/amphp/parallel/.github/workflows/ci.yml
		- vendor/amphp/process/.github/workflows/ci.yml
	- FILE_MISSING
		- vendor/andrewdalpino/okbloomer/.github/FUNDING.yml
		- vendor/andrewdalpino/okbloomer/.github/workflows/ci.yml
- photos
	- INVALID_HASH
		- vendor/hexogen/kdtree/.github/workflows/tests.yml

Nextcloud Logs

I don't think the 30MB log file is helpful.
tail -5 /extra/server/nextcloud/nextcloud.log
  {"reqId":"abgGm6e2MeDYflpwum2YggAAAQU","level":1,"time":"March 16, 2026 13:33:16","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"8ef47d68-3b37-428a-ae92-5aa8a7dc6a22","data":[]}
  {"reqId":"abgGpMPkE81TzJ56x83kFAAAAUA","level":1,"time":"March 16, 2026 13:33:25","remoteAddr":"192.168.0.13","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"e55a9146-4276-4745-985a-246ae0809987","data":[]}
  {"reqId":"abgGr8PkE81TzJ56x83kFwAAAUg","level":1,"time":"March 16, 2026 13:33:35","remoteAddr":"127.0.0.1","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Linux) mirall/3.17.4daily (Nextcloud, fedora-6.18.12-200.fc43.x86_64 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"0cd7a78e-9566-4f6a-9362-422ef2c105cd","data":[]}
  {"reqId":"abgGu8PkE81TzJ56x83kHAAAAU4","level":1,"time":"March 16, 2026 13:33:48","remoteAddr":"192.168.0.15","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"b0064110-7e56-420c-a7f1-f780dbeab18c","data":[]}
  {"reqId":"abgGxMPkE81TzJ56x83kIQAAAUU","level":1,"time":"March 16, 2026 13:33:57","remoteAddr":"192.168.0.13","user":"bobw","app":"no app in context","method":"GET","url":"/nextcloud/ocs/v1.php/cloud/user?format=json","scriptName":"/nextcloud/ocs/v1.php","message":"The user config key files/quota is not defined in the config lexicon","userAgent":"Mozilla/5.0 (Windows) mirall/4.0.6 (build 20260122) (Nextcloud, windows-10.0.19045 ClientArchitecture: x86_64 OsArchitecture: x86_64)","version":"32.0.5.0","clientReqId":"9abf3c24-82e0-4c45-a2f9-9baf411b3cf4","data":[]}

Additional info

I suspect this behaviour is the cause real problems in my production environment.
It is reproducable, but may take thousands of attempts to capture.
That is possibly because of the relative timing of the file creation and the slow curl accesses.

Start by reproducing the issue with the documented curl PROPFIND loop against remote.php/dav/files and the provided file-creation sequence, using the reported server and client versions. Compare the two observed getetag values and timestamps, then trace the server-side handling of the WebDAV request to identify why an unchanged file receives a new etag. Done means repeated reproduction no longer changes the etag for an unchanged file, with a regression test covering the timing scenario.