[Bug]: F-21 Overwriting a file within the same second keeps the old etag
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start with apps/dav/lib/Connector/Sabre/File.php and the unit test that fails on Nextcloud 35.0.1. Reproduce three same-second overwrites of a local file and trace how the cached etag is handled after a DAV upload. Done means each content-changing overwrite receives a new etag while renames and other non-content operations retain theirs.
Written by the indexing model from the issue text.
Description
⚠️ This issue respects the following points: ⚠️
- This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
- This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
- I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
- I agree to follow Nextcloud's Code of Conduct.
- I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description
F-21 · Overwriting a file within the same second keeps the old etag (upstream #63994)
| Severity | Medium (clients do not see the change, Text and sync clients keep stale content) |
| Component | apps/dav/lib/Connector/Sabre/File.php, local storage etag |
| Affects | 35.0.1 |
| Upstream | https://github.com/nextcloud/server/issues/63994 |
| Verified | Yes, on the test server and with a unit test that fails on 35.0.1 |
Measurement (local storage, three PUTs of 4 bytes within one second)
35.0.1: "ca1d3d5e…" "ca1d3d5e…" "ca1d3d5e…" same etag
patched: "784b5dca…" "23f010bc…" "6ac0fd38…" new etag each time
Root cause
The local storage derives the etag from mtime (seconds), inode, device and size. Same size, same
second and a reused inode give the same etag although the content changed.
Fix
After a DAV upload to an existing file, when the cache still has the previous etag, a new one is set.
Renames and other operations that do not change content keep their etag.
Steps to reproduce
see the top
Expected behavior
see the top
Nextcloud Server version
35
Operating system
None
PHP engine version
None
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
- Dominant language
- PHP
- Stars
- 37k
- Forks
- 5.3k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 702
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nextcloud/server
-
0. Needs triage 35-feedback bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
0. Needs triage 35-feedback bug
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
0. Needs triage 35-feedback bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
0. Needs triage 35-feedback bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
0. Needs triage 35-feedback bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
All issues in nextcloud/server
Similar issues
-
Lead create/update: a product row without a "product_id" key passes LeadForm validation and fails in the database (500)Possibly taken @Arslan-TR claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
krayin/laravel-crm#2681 ·
Maintainers usually reply within 2 days
-
[CoreBundle] Migrations are silently skipped on MariaDB with DBAL 4 (AbstractMigration::isMySql())OpenPotential Bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Sylius/Sylius#19270 · 1 comment · 4 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
invoiceninja/invoiceninja#13320 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day