[Bug]: Filename not validated when calling `IFolder->newFile()`

[mejo-]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

With the new IFilenameValidator implementation I would expect IFolder->newFile() to throw an error if passed file name is invalid. But it seems like that's not the case. newFile() still returns a File object and only further operation on this object fail. I guess there's a bug somewhere.

I discovered this issue while developing nextcloud/text#6271.

Steps to reproduce

1. Call IFolder->newFile() with windows compatibility turned on and an invalid filename as argument
2. See that it returns a File object instead of throwing an exception

Expected behavior

I would expect IFolder->newFile() to throw an error if passed file name is invalid.

Installation method

None

Nextcloud Server version

master

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

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

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[susnux]

This is expected behavior.
You need to check the validity before creating.

It is only checked in webdav. The reason is that we use that api also for internal things that break with that validation (setup, appdata, updater).

So all user facing files should be validated but the IFolder and FilesView api are also used for private stuff

[mejo-]

Ok, thanks for clarification. I would have expected server functions to do the validation when a file gets created. Let's close this then.

[susnux]

I would have expected server functions to do the validation when a file gets created.

Yes normally agree, but those functions also can be used for app data, which does not have those limitations.
So no validation, thats why we have the public interface \OCP\Files\IFilenameValidator

[kesselb]

It looks like we already validate oc_filecache.path (4000), but not oc_filecache.name (250). Since appdata is also tracked in oc_filecache, I’d suggest reopening this issue and ensuring that newFile / the FileApi at least validates whether records with such information (e.g. names longer than 250) can actually be written.