nextcloud / nextcloud/files_lock
LOCK request fails with NotFoundException for paths containing special characters (umlauts) after URL-decoding
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 39
- Forks
- 10
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 48
Description
Description
LOCK requests via WebDAV consistently fail with OCP\Files\NotFoundException for file paths containing special characters (German umlauts in our case), even though the file exists and can be read/written normally.
Environment
- Nextcloud version: 34.0.2.1
- files_lock version: 34.0.1
- Client: Nextcloud Desktop Client (mirall) 33.0.5, macOS (arm64)
- PHP: (bitte eure PHP-Version ergänzen)
Steps to reproduce
- Create/use a file with a special character (umlaut) in the folder or file name, e.g.:
Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx - Open the file via the desktop client (triggers a WebDAV
LOCKrequest) - Observe the server log
Expected behavior
The file should be locked successfully, same as for files without special characters.
Actual behavior
Server throws OCP\Files\NotFoundException and the request fails with an uncaught exception. This has been reproduced multiple times, on different files, all with special characters (umlauts) in the path.
Log excerpt
{
"app": "webdav",
"method": "LOCK",
"url": "/remote.php/dav/files/<user>/Projects/_TEAM_B%C3%9CRO/___Cover_Letter_Template%20.docx",
"message": "/<user>/files/Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx",
"exception": {
"Exception": "OCP\\Files\\NotFoundException",
"Message": "/<user>/files/Projects/_TEAM_BÜRO/___Cover_Letter_Template .docx",
"Trace": [
{"file": ".../lib/private/Files/Node/LazyFolder.php", "line": 141, "function": "get", "class": "OC\\Files\\Node\\Root"},
{"file": ".../apps/files_lock/lib/Service/FileService.php", "line": 119, "function": "get", "class": "OC\\Files\\Node\\LazyFolder"},
{"file": ".../apps/files_lock/lib/DAV/LockPlugin.php", "line": 192, "function": "getFileFromAbsoluteUri", "class": "OCA\\FilesLock\\Service\\FileService"},
{"file": ".../3rdparty/sabre/event/lib/WildcardEmitterTrait.php", "line": 89, "function": "httpLock", "class": "OCA\\FilesLock\\DAV\\LockPlugin"}
]
}
}
Additional context
- The file itself opens, edits, and saves correctly outside of the LOCK mechanism (no data loss).
- Only the lock acquisition fails — the practical impact is a missing collision-protection warning when multiple users edit the same file concurrently.
- Reproduced on at least two different files/folders, both containing umlauts (
Ü,ö) in the path, suggesting the issue lies in howFileService::getFileFromAbsoluteUri()resolves URL-decoded paths with non-ASCII characters, rather than being specific to one file.
Contributor 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.
Research direction
Start in apps/files_lock/lib/Service/FileService.php, especially getFileFromAbsoluteUri(), and trace how the LOCK request reaches it through apps/files_lock/lib/DAV/LockPlugin.php. Reproduce the WebDAV LOCK request with the umlaut-containing path and verify that the existing file is resolved and locked without OCP\Files\NotFoundException.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100