Windows: invalid-filename rename dialog builds remote PROPFIND URLs without a path separator

[hardolf]

⚠️ Before submitting, please verify the following: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I have searched for it).
• Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
• I agree to follow Nextcloud's Code of Conduct

Bug description

When the "Invalid filename" dialog is used to rename a file, the client issues PROPFIND
requests to check the name against the server. The remote URL is assembled by joining the
folder's remote path and the file name without a path separator, so every one of these
requests addresses a path that cannot exist.

Sync folder D:\benth\_NcBug → remote /_NcBug. The file being renamed is
trailing period.; the new name typed into the dialog is no trailing period:

OCC::PropfindJob created for "https://…" + "/_NcBugtrailing period."
OCC::PropfindJob created for "https://…" + "/_NcBugno trailing period"

PROPFIND of QUrl(".../remote.php/dav/files/USER/_NcBugno trailing period")
    FINISHED WITH STATUS "ContentNotFoundError …"
    *not* successful, http result code is 404

Expected in both cases is /_NcBug/trailing period. and /_NcBug/no trailing period.
The same sync session builds correct URLs everywhere else — for comparison, from the sync
engine in the same log:

"CUSTOM" "PROPFIND" ".../remote.php/dav/files/USER/_NcBug/"           → OK
"PUT"              ".../remote.php/dav/files/USER/_NcBug/trailing space" → 201 Created

so the missing separator is specific to the paths this dialog constructs.

The consequence is not cosmetic. Whatever these requests are meant to establish — most
obviously whether the target name is already taken on the server — they cannot establish
it: a 404 from a malformed URL is indistinguishable from a 404 meaning "the name is free".
A name that genuinely exists on the server would produce exactly the same answer, and the
dialog would proceed as though it were available. The check is inert, and silently so.

This is independent of the Win32 path handling reported in #10836; it would remain
after that is fixed.

Steps to reproduce

1. On Windows, set up a sync pair with virtual files disabled.

2. Place a file with an invalid name in it — e.g. through the raw path, since Explorer
   cannot create one:

   [System.IO.File]::WriteAllText("\?\C:\path\to\syncfolder\trailing period.", "x")

3. Run the client with --logdebug --logflush --logfile <path>.

4. Let it sync until the "Invalid filename" warning appears, then click "Rename file",
   type a new name and confirm.

5. In the log, find the OCC::PropfindJob created for lines: the folder path and the file
   name are concatenated with no / between them, and the requests return 404.

Only the trailing-period case was tested here. Nothing in the constructed path appears to
depend on which character made the name invalid, but I have not verified the others.

Expected behavior

The dialog's remote lookups should address the same path the sync engine uses for the file,
<folder remote path>/<file name>, so that the result means what the caller takes it to
mean.

Which files are affected by this bug

trailing period. (any file that triggers the invalid-filename dialog)

Operating system

Windows

Which version of the operating system you are running.

Windows 11 Pro 26200 (25H2)

Installation method

Official Windows MSI

Nextcloud Server version

33.0.9 (hosted)

Nextcloud Desktop Client version

34.0.3 (build 20260826)

Did this occur after an update or on a clean installation?

Clean desktop client installation

Are you using the Nextcloud Server Encryption module?

No

Are you using an external user-backend?

• Default internal user-backend
• LDAP or Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

Additional info

Prior issues searched. #6760 (closed) covered earlier defects in this dialog — duplicate
Cancel buttons and the OK path; #8108 (open) covers the OK button not being debounced in the
same dialog. Neither mentions the malformed remote path.

Related. #10836 — the same dialog's local rename fails because
FileSystem::rename() does not use the long-path form it computes.

Log. Trimmed excerpt attached (client run with --logdebug --logflush).

Nextcloud-issue-log-excerpt.log

Ref. issue: #10836