[Bug]: Synchronization fails if there are special characters in file names in Nextcloud Desktop Client 3.14

[skorpions2000]

⚠️ 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've searched 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

After updating to Nextcloud Desktop Client version 3.14, synchronization fails for files and folders that contain certain special characters in their names. Specifically, characters like "ż" and "Ł" cause the synchronization process to halt. For example, a folder named "Może" will not synchronize, but renaming it to "Moze" allows synchronization to proceed successfully. Rolling back to version 3.13.4 resolves this issue, and synchronization works as expected with these special characters.

Steps to reproduce

1. Install Nextcloud Desktop Client version 3.14 on Windows 10 using the Official Windows MSI package.
2. Create a file or folder with a name containing special characters such as "ż" or "Ł" (e.g., "Może" or "Łódź").
3. Ensure the Nextcloud Desktop Client is running and connected to the Nextcloud Server.
4. Wait for automatic synchronization or attempt to manually synchronize.
5. Observe that the file or folder does not synchronize to the server.

Expected behavior

Files and folders with special characters like "ż" and "Ł" in their names should synchronize successfully, as they did in previous versions (e.g., 3.13.4).

Which files are affected by this bug

Any files or folders with names containing special characters such as "ż" (Unicode U+017C) or "Ł" (Unicode U+0141).

Operating system

Windows

Which version of the operating system you are running.

Windows 11

Package

Official Windows MSI

Nextcloud Server version

25.0.0

Nextcloud Desktop Client version

3.14

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

Updated to a major version (ex. 3.3.6 to 3.4.0)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

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

Nextcloud Server logs

{
  "reqId": "REDACTED_REQUEST_ID_1",
  "level": 3,
  "time": "2024-09-23T09:34:28+02:00",
  "remoteAddr": "REDACTED_IP_ADDRESS",
  "user": "REDACTED_USER_ID",
  "app": "no app in context",
  "method": "PUT",
  "url": "/remote.php/dav/files/REDACTED_USER_ID/Folder_with_special_char_%C5%81/Financial_Documents/2024/Report_2Q2024.pdf",
  "message": "Expected file size of 1178702 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 360448 bytes. This could either be a network problem on the sending side or a problem writing to the storage on the server side.",
  "userAgent": "Mozilla/5.0 (Windows) mirall/3.14.0stable-Win64 (build 20240914) (Nextcloud, windows-10.0.22631 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "22.2.10.2",
  "exception": {
    "Exception": "Sabre\\DAV\\Exception\\BadRequest",
    "Message": "Expected file size of 1178702 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 360448 bytes. This could either be a network problem on the sending side or a problem writing to the storage on the server side.",
    "Code": 0,
    "Trace": [
      {
        "file": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php",
        "line": 155,
        "function": "put",
        "class": "OCA\\DAV\\Connector\\Sabre\\File",
        "type": "->"
      },
      // Additional trace entries...
    ],
    "File": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php",
    "Line": 275,
    "CustomMessage": "--"
  }
}
{
  "reqId": "REDACTED_REQUEST_ID_2",
  "level": 3,
  "time": "2024-09-23T09:34:28+02:00",
  "remoteAddr": "REDACTED_IP_ADDRESS",
  "user": "REDACTED_USER_ID",
  "app": "no app in context",
  "method": "PUT",
  "url": "/remote.php/dav/files/REDACTED_USER_ID/Folder_with_special_char_%C5%81/Financial_Reports/2023/Annual_Report_2023.pdf",
  "message": "Expected file size of 4885474 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 16384 bytes. This could either be a network problem on the sending side or a problem writing to the storage on the server side.",
  "userAgent": "Mozilla/5.0 (Windows) mirall/3.14.0stable-Win64 (build 20240914) (Nextcloud, windows-10.0.22631 ClientArchitecture: x86_64 OsArchitecture: x86_64)",
  "version": "22.2.10.2",
  "exception": {
    "Exception": "Sabre\\DAV\\Exception\\BadRequest",
    "Message": "Expected file size of 4885474 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 16384 bytes. This could either be a network problem on the sending side or a problem writing to the storage on the server side.",
    "Code": 0,
    "Trace": [
      {
        "file": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php",
        "line": 155,
        "function": "put",
        "class": "OCA\\DAV\\Connector\\Sabre\\File",
        "type": "->"
      },
      // Additional trace entries...
    ],
    "File": "/var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php",
    "Line": 275,
    "CustomMessage": "--"
  }
}

Additional info

• Rolling back to Nextcloud Desktop Client version 3.13.4 (Nextcloud-3.13.4-x64.msi) resolves the issue; synchronization with special characters in file and folder names works as expected in that version.
• The issue appears to be specific to certain Unicode characters that were previously supported.
• The server logs indicate a mismatch between the expected file size and the actual bytes read and written, possibly related to the special characters in the file paths.

[btx97]

There may be a coding issue in desktop 3.14. When update to 3.14, the desktop failed to lauch because 3.14 can't recognize special characters, the chinese words in my case. After reinstalling 3.13 desktop, the name of the root directory, should be in chinese, was a mass, in the setting section of the desktop. It had to remove the synchronization link, and match the local and remote directories to make the desktop 3.13 work properly.

[chemiker]

This issue hit me on macOS (14.7) as well after upgrading to 3.14.0. A downgrade to 3.13 fixed the issue. However, as @btx97 mentioned I had to relink my sync dictionary. For me the issue was not related to characters in filename but filesize. Small files (up to something like 7mb) worked well. For everything bigger the sync failed.

[ChiMuYuan]

I also encountered issues with Chinese folder names and large files.

Win11 23H2
Nextcloud 29.0.7
Client 3.14.0

Based on my testing:
If the folder name is in Chinese, uploading large files (MP4 92.5MB) will fail to sync, but small files (PDF 1.6MB, PPTX 572KB) can sync successfully. If the folder name is in English, both large files (MP4 92.5MB) and small files (PDF 1.6MB, PPTX 572KB) sync without issues.

In other words, small files sync successfully in all cases, but large files fail to sync when the folder name is in Chinese. I'm not sure if this is related to some of my settings or environment. If you need me to provide any configurations or environment details, please let me know, and I will provide them.

Thank you

[wojciechczyz]

I see the same issue with spanish accented characters of double .. in the file or directory name.
Important: once such file synchronization is attempted, synchronization breaks and no further files are synchronized.

[fulafisken]

I have users reporting this error from Mac computers as well, so it might not be windows specific. In this case with Swedish letters öäå. It is still present in the 3.14.50 daily build as well as the latest "stable" 3.14.

[kubrickfr]

Duplicate of #7149?

[Webbeh]

( #7171 (comment) )

This encoding issue happens consistently everytime I revert from 3.14 to 3.13.4. The encoding issue does not appear in the 3.14 window, it's only after reverting.

[mgallien]

this is now solved with the release of 3.14.1

[DoctorSaikesi]

thought i can't upload file because of Chinese file name, but it turns out the filename is too long