⚠️ Before submitting, please verify the following: ⚠️
Bug description
On Linux, Nextcloud Desktop Virtual Files in suffix mode fail to synchronize valid remote filenames when adding the .nextcloud suffix makes the local placeholder filename exceed the filesystem NAME_MAX limit.
The affected filesystem is Btrfs with:
NAME_MAX = 255 bytes
The original remote filename is valid and below the filesystem limit. For example, an original filename can be 246 bytes long.
However, when Virtual Files are enabled, Nextcloud Desktop tries to create:
.nextcloud
The .nextcloud suffix adds 10 bytes, so a valid 246-byte filename becomes 256 bytes and Btrfs rejects it with:
File name too long
The Nextcloud Desktop log confirms that the failure occurs while creating an ItemTypeVirtualFile placeholder:
CSyncEnums::ItemTypeVirtualFile
OCC::SyncFileItem::Down
Could not complete propagation ... with error: "File name too long"
The original file exists correctly on the Nextcloud Server. The problem occurs locally when Nextcloud Desktop creates the .nextcloud placeholder.
This makes valid filenames between approximately 246 and 255 bytes impossible to synchronize using Linux Virtual Files suffix mode.
This is particularly easy to encounter with UTF-8 filenames such as Arabic filenames, where characters commonly consume multiple bytes.
Steps to reproduce
-
Use Linux on a filesystem with NAME_MAX=255, such as Btrfs.
-
Enable Virtual Files in Nextcloud Desktop using suffix mode.
-
Upload/create on the Nextcloud Server a filename that is valid on the filesystem but close to NAME_MAX.
For example, create a filename approximately 246 bytes long.
A reproducible test filename can be generated with:
name="$(printf 'ا%.0s' {1..121}).txt"
printf '%s' "$name" | wc -c
-
Let Nextcloud Desktop synchronize the folder.
-
The client discovers the remote file successfully.
-
Nextcloud Desktop attempts to create the local virtual placeholder:
.nextcloud
-
The resulting filename exceeds 255 bytes.
-
Synchronization fails with:
File name too long
The client log shows:
CSyncEnums::ItemTypeVirtualFile
CSYNC_INSTRUCTION_NEW
OCC::SyncFileItem::Down
followed by:
Could not complete propagation ... with status OCC::SyncFileItem::NormalError and error: "File name too long"
Expected behavior
A remote filename that is valid and does not exceed the target filesystem NAME_MAX should be synchronizable with Virtual Files enabled.
Nextcloud Desktop should handle filenames close to NAME_MAX without requiring users to rename the original server file.
The internal .nextcloud placeholder implementation should not make an otherwise valid filename impossible to synchronize.
The client could check NAME_MAX before creating the suffix-based placeholder and use another representation when <filename>.nextcloud would exceed the filesystem limit.
Which files are affected by this bug
A UTF-8 Arabic test filename approximately 246 bytes long, e.g. a filename generated with: name="$(printf 'ا%.0s' {1..121}).txt" The original filename is valid (<255 bytes), but <filename>.nextcloud exceeds NAME_MAX and fails. In my real dataset, 6 files are currently affected, all with original filename lengths close to the 255-byte limit.
Operating system
Linux
Which version of the operating system you are running.
Fedora release 44 (Forty Four)
Installation method
Official Linux AppImage
Nextcloud Server version
34.0.3.2
Nextcloud Desktop Client version
34.0.2
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?
Nextcloud Server logs
Additional info
No response
Bug description
On Linux, Nextcloud Desktop Virtual Files in suffix mode fail to synchronize valid remote filenames when adding the
.nextcloudsuffix makes the local placeholder filename exceed the filesystem NAME_MAX limit.The affected filesystem is Btrfs with:
NAME_MAX = 255 bytes
The original remote filename is valid and below the filesystem limit. For example, an original filename can be 246 bytes long.
However, when Virtual Files are enabled, Nextcloud Desktop tries to create:
.nextcloud
The
.nextcloudsuffix adds 10 bytes, so a valid 246-byte filename becomes 256 bytes and Btrfs rejects it with:File name too long
The Nextcloud Desktop log confirms that the failure occurs while creating an ItemTypeVirtualFile placeholder:
CSyncEnums::ItemTypeVirtualFile
OCC::SyncFileItem::Down
Could not complete propagation ... with error: "File name too long"
The original file exists correctly on the Nextcloud Server. The problem occurs locally when Nextcloud Desktop creates the
.nextcloudplaceholder.This makes valid filenames between approximately 246 and 255 bytes impossible to synchronize using Linux Virtual Files suffix mode.
This is particularly easy to encounter with UTF-8 filenames such as Arabic filenames, where characters commonly consume multiple bytes.
Steps to reproduce
Use Linux on a filesystem with NAME_MAX=255, such as Btrfs.
Enable Virtual Files in Nextcloud Desktop using suffix mode.
Upload/create on the Nextcloud Server a filename that is valid on the filesystem but close to NAME_MAX.
For example, create a filename approximately 246 bytes long.
A reproducible test filename can be generated with:
name="$(printf 'ا%.0s' {1..121}).txt"
printf '%s' "$name" | wc -c
Let Nextcloud Desktop synchronize the folder.
The client discovers the remote file successfully.
Nextcloud Desktop attempts to create the local virtual placeholder:
.nextcloud
The resulting filename exceeds 255 bytes.
Synchronization fails with:
File name too long
The client log shows:
CSyncEnums::ItemTypeVirtualFile
CSYNC_INSTRUCTION_NEW
OCC::SyncFileItem::Down
followed by:
Could not complete propagation ... with status OCC::SyncFileItem::NormalError and error: "File name too long"
Expected behavior
A remote filename that is valid and does not exceed the target filesystem NAME_MAX should be synchronizable with Virtual Files enabled.
Nextcloud Desktop should handle filenames close to NAME_MAX without requiring users to rename the original server file.
The internal
.nextcloudplaceholder implementation should not make an otherwise valid filename impossible to synchronize.The client could check NAME_MAX before creating the suffix-based placeholder and use another representation when
<filename>.nextcloudwould exceed the filesystem limit.Which files are affected by this bug
A UTF-8 Arabic test filename approximately 246 bytes long, e.g. a filename generated with: name="$(printf 'ا%.0s' {1..121}).txt" The original filename is valid (<255 bytes), but
<filename>.nextcloudexceeds NAME_MAX and fails. In my real dataset, 6 files are currently affected, all with original filename lengths close to the 255-byte limit.Operating system
Linux
Which version of the operating system you are running.
Fedora release 44 (Forty Four)
Installation method
Official Linux AppImage
Nextcloud Server version
34.0.3.2
Nextcloud Desktop Client version
34.0.2
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?
Nextcloud Server logs
Additional info
No response