Missing Names and Extensions
Two settings decide whether files arriving without a name, or without an extension, are accepted.
Where to find it
Architect Panel → Configuration:
- Site Settings — the File Uploads and Audio/Video Conversion groups
Files without extensions
Allowed by default. Plenty of legitimate files have no extension — anything produced on a system that does not use them, files renamed in transit, and some exports.
The cost is that neither the platform nor the user’s device can tell what the file is from its name, so it downloads as something nobody can open.
Files without names
Refused by default, and that default is right. A file arriving with no name at all is nearly always a fault — a broken form, a misbehaving integration, or something deliberate.
Accepting them means storing files under generated names that nobody can identify afterwards.
Neither is a security control
The important caution. An extension tells you what a file claims to be, not what it is. A document renamed to end in an image extension is still a document, and one that is genuinely dangerous is not made safe by its name.
File scopes, storage location and how a file is served back are the controls. These two settings are about usability.
Decide by what your users send
If your uploads come from an integration producing extensionless files, allow them. If they come from people using ordinary devices, requiring an extension catches mistakes early and produces files that open when downloaded.
A refusal must be explained
Whichever way you set them, the message when a file is rejected should say what was wrong and what to do. "Upload failed" produces a support call; "this file has no name — please rename it and try again" does not.
Watch the error log
A sudden run of rejected uploads usually means an integration has changed rather than that users have. The log is where that shows.
Consider the download experience
A stored file with no extension is one somebody downloads and cannot open. If you accept them, consider whether the platform can supply a sensible name on download instead.
Test both
Upload a file with no extension and one with no name, and see what happens. That is a two-minute check on behaviour that is otherwise only discovered by a user.
Worked example
An organisation allows extensionless files because a supplier integration produces them, and refuses nameless ones. The rejection message names the problem. A run of failures in the error log identified a form change on the supplier’s side within a day.
Recommendations
- Refuse nameless files — they are nearly always a fault.
- Do not treat extensions as security.
- Explain every refusal in the message.
- Watch the log for a run of rejections.