Repository navigation
[Bug]: Filename not validated when calling IFolder->newFile() #47563
Description
⚠️ 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
- Call
IFolder->newFile()with windows compatibility turned on and an invalid filename as argument - 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
Activity
susnux commentedon Aug 28, 2024
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- commentedon Sep 4, 2024
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 commentedon Sep 4, 2024
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\IFilenameValidatorkesselb commentedon Sep 25, 2025
It looks like we already validate
oc_filecache.path(4000), but notoc_filecache.name(250). Since appdata is also tracked inoc_filecache, I’d suggest reopening this issue and ensuring thatnewFile/ the FileApi at least validates whether records with such information (e.g. names longer than 250) can actually be written.