🪟📁📄 Ability to enforce windows compatible file names on the server

[AndyScherzinger]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
In some scenarios with a large chunk of the user base being Windows users, using the Desktop client for example sync conflict can get created easily via the web interface, other clients or directly via any client software supporting WebDAV by creating files or folders that cannot be synced down to Windows ever.

Describe the solution you'd like
Add a setting to 'enforce windows compatible file names' on the server, so when the user tries to rename/create files/folders that would generate conflict when syncing, the server would prevent the action. This setting should be optional and needs to be turned on explicitly.
Also there is no logic expected to migrate existing data, just to prevent it from the moment on the setting is active.

• [Bug]: renaming file by just changing case leads to strange results (on SMB storage and others) #40690 should be a stretch goal
• define list invalid characters
• [feature] Allow to enforce case insensitive filenames #45130

Describe alternatives you've considered
None, given the fact that the person creating a file/folder might not be the one being affected by it and the affected person might not have the permissions on the system to change the names, i.e. when shared read-only.

[tobiasKaminsky]

Subscribing myself, as I think this is then also a task for clients.

• If server returns a specific error message, clients should show a correct info
• if setting is enabled via capabilities, clients can directly prohibit renaming/creating such a file

[susnux]

@tobiasKaminsky we need this implemented / fixed on the clients, server and WebUI are already done:

• Desktop: Implementing usage of forbidden_chars for file/folder uploads desktop#6447
• Android: Implementing usage of forbidden_chars for file/folder uploads android#12576
• iOS: Implementing usage of forbidden_chars for file/folder uploads ios#2802

Implementation: Get the capability "forbidden_filename_characters" from the files app. This is an array of forbidden characters (could be multibyte characters, so it is an array of strings). If any of the strings in the array matches the filename it is considered invalid.

[SystemKeeper]

Besides some characters not allowed on windows, there are more rules that need to be taken into account, e.g. a Filename is also not allowed to end with a dot or a space. There are also some reserved filenames.
See https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions for details.

[susnux]

Yes but having the forbidden characters implemented in clients is a good first step and also allows to configure other compatibility (like with some filesystems that forbid just :).

See https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions for details.

This is also only partially true, Windows supports a lot of naming things, but the Explorer simply does not, like trailing . is working just win32 API needs the ? flag to disable path normalization (and of course Explorer fails to handle it).
Just like with Mac where some buggy GUI application forbid files with colon in the name, while on OS layer this is pretty fine.

But we probably should still enforce the character + the trailing space / dot rules. About the path length we can not do much, that depends on the users mount point and file type (e.g. for spreadsheets the table name counts into the path length 🤦).

[skjnldsv]

Maybe that is relevant?

server/config/config.sample.php

Lines 1972 to 1983 in 8c10c78

	/**
	* Blacklist characters from being used in filenames. This is useful if you
	* have a filesystem or OS which does not support certain characters like windows.
	*
	* The '/' and '\' characters are always forbidden.
	*
	* Example for windows systems: ``array('?', '<', '>', ':', '*', '|', '"', chr(0), "\n", "\r")``
	* see https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
	*
	* Defaults to ``array()``
	*/
	'forbidden_chars' => [],

[susnux]

Not only it is not only specific characters but also files and casing, and that list for characters is not complete (missing e.g. char 1-31).

[AndyScherzinger]

You also can't have a space or a dot at the end of a folder name on Windows.

[skjnldsv]

You also can't have a space or a dot at the end of a folder name on Windows.

pretty sure we trim the names on NC side 🤔

[AndyScherzinger]

pretty sure we trim the names on NC side 🤔

created via "New" in the webUI

and also

[susnux]

pretty sure we trim the names on NC side 🤔

No, spaces are pretty valid on Mac and Linux. But we restrict even on Linux to not include ascii 0-31 (including tab).

[susnux]

After discussion with @Altahrim and @come-nc we came to the conclusion the best is to keep the configuration generic but just provide a "preset" for windows.
Meaning we have multiple options to fine tune our file restrictions:

• Forbidden filename characters (already implemented by us)
• Forbidden filenames (already implemented by us)
• Forbidden filename prefixes (needed for windows due to namespace support)
• Forbidden filename extensions (optional but makes sense to replace unused filename regex)

[susnux]

@AndyScherzinger @jancborchardt

How do we handle this use case:

1. No rules enabled
2. User uploads file that is not compatible but currently allowed
3. Admin enabled Windows support

Now the behavior can be:

1. No access to the files anymore
2. Readonly access with ability to rename
3. Update but not new files with those rules

3 is probably very hard and requires work on internal filesystem -> 2 would be be from my point of view.

[tobiasKaminsky]

Capabilities:

• provides 4 (above) options with each forbidden characters/patterns

Webdav:

• method: put, mkcol, copy, move
• if wrong character
• http 400 return, with sabre dav exception

OCS:

• find all endpoints, e.g. create new file from template via direct editing (/ocs/v2.php/apps/files/api/v1/directEditing/create)

@susnux checks if exception can be localised via http header

I can provide a LTD with branch/app, so that we can all have the same state.

[AndyScherzinger]

@susnux I would say option (3). Why do you think it is hard? Wouldn't is just mean that while updating an existing file's content the checks simply won't be executed?

So the checks would be on

• Create
• Move (including rename)

[susnux]

Status update:

• The server provides a new interface for filename validation that covers all of those points (feat: Add IFilenameValidator to have one consistent place for filename validation #46371)
• The server now provides the capabilities to allow validation on clients (feat: Add new forbidden filename options to Capabilities #46414)
• Migrate all filename validation in server to the new interface
  • refactor: Migrate filename validation from Storage and Util to FilenameValidator #46538
  • feat: Add forbidden_filename_basenames config option #46545
  • refactor: Migrate some legacy and core functions to IFilenameValidator #46571
  • More...
• Web UI validates filenames
  • Library update: feat(filename): Improve filename validation to support Nextcloud 30 capabilities nextcloud-libraries/nextcloud-files#1013
  • Update library in server
• Provide UI button to easily fill all config values for Windows support: feat(files): Allow to configure Windows filename compatibility in the settings #46558
• Clients validate filenames based on capabilities (TBD?)