Restricted Characters
The Files.com platform has few restrictions regarding characters that can be used in file and folder names. For both file names and folder names, the following characters cannot be used:
/(forward slash)\(backslash)- Zero-width space (
U+200B)
Rename files and folders to remove or replace these characters before uploading them to Files.com. The web interface automatically removes zero-width spaces from uploaded file names. Zero-width spaces are otherwise prohibited because their invisible appearance can make distinct names look identical.
Neither a file nor a folder can have an empty name or be named . (a single period) or .. (a double period). Periods within a longer name, such as report.final.txt, are permitted.
Unicode Names
Files.com preserves the Unicode spelling of accepted file and folder names. It uses a normalized form when comparing names to determine whether they refer to the same location.
A name is rejected if its comparison form contains a forward slash (/) or backslash (\), is empty, or is exactly . or ... This keeps individual names distinct from path structure, so file operations and folder permissions refer to the intended location.
For example, parent／child.txt contains a fullwidth slash (／, U+FF0F) that becomes / during comparison. Files.com rejects that name rather than treating it as a file inside a folder named parent. Replace the character, for example with a hyphen to produce parent-child.txt. Names consisting of a fullwidth period (．, U+FF0E) or two fullwidth periods are also rejected because they compare as . or ...
Whitespace-only names, including names made only of nonbreaking spaces, are rejected. These checks apply to every file and folder name in a path. The separate trailing-whitespace rules also apply: folder names cannot end in whitespace, while file names in native Files.com storage can contain trailing whitespace when the rest of the name is valid.
When you create a folder permission or an API key path restriction, or change its path, the names in that path must satisfy the same rule.
Restricted Characters on Other Systems
Operating systems such as Windows, Linux, and Mac each have their own specific restrictions for which characters can be used to name a file or folder. Additionally, 3rd party service providers can overlay their own restrictions. Cloud based object storage usually has fewer restricted characters than on-premise systems. It is not practical for Files.com to maintain a database of all restrictions that may apply.
When a character is restricted by a system then it cannot be used for file names nor for folder or directory names on that system.
When using a Remote Server integration on your Files.com site, names must satisfy Files.com's rules and the remote system's own restrictions. For better interoperability, choose names that are valid on every system involved in the transfer.
Some examples of restricted characters on other systems include:
<(less than)>(greater than):(colon)"(double quote)/(forward slash)\(backslash)|(vertical bar or pipe)?(question mark)*(asterisk)#(hash or pound)%(percent)&(ampersand)@(at)^(caret)$(dollar)!(exclamation)
Trailing Periods and Spaces on Windows
Restrictions can also apply to the position of a character within a name. On Windows, Microsoft's file naming rules do not allow file or folder names that end with a period or a space.
Files.com native storage allows names that end with a period. A file or folder with this type of name opens normally in the Files.com web interface, but Windows File Explorer cannot open it, including when you access your files using the Desktop App. Rename the file or folder to remove the trailing period or space so that Windows can open it.
On a Remote Server Mount, the remote system can instead remove a trailing period when resolving a path. If it opens HR and HR. as the same folder, Files.com still evaluates permissions on those different paths separately. A fence on HR does not keep users with a broader parent grant from reaching the contents through HR.. Renaming the folder does not separate that access; use a folder or mount arrangement outside those users' broader grants, as explained in Path Matching on Mounted Storage.
The official SDKs and CLI App write downloads to local paths as the operating system resolves them. On Windows, that resolution can remove trailing periods or spaces, so files named report.txt, report.txt., and report.txt (with a trailing space) can be written to one local file. Source files in native Files.com storage remain separate, with their own folder permissions; those permissions do not control the downloaded copy.
Effects of Restricted Characters
Files.com checks destination names when uploading files, creating folders, renaming items, and copying or moving files and folders. This includes destinations produced by Syncs and Automations, ZIP extraction, and restores. An Automation's configured paths and the names it generates must satisfy the same naming rules.
Existing stored names are not renamed automatically. On a Remote Server Mount, an item whose name fails the Unicode name checks does not appear in Files.com folder listings. Files.com rejects every request to its path, regardless of the requesting user or API key. The item remains unchanged on the remote system; rename it there to a valid name to make it available through Files.com.
If an operation is rejected because of a name, check the affected file name and every folder name in its destination path. Rename the affected item or correct the workflow's destination before retrying. Error wording varies by client and destination system; messages containing "invalid", "permission denied", "cannot write", "cannot store", or "unknown entity" can indicate a naming problem.
Uploading
Inbox email attachments receive filename conversion before storage: forward slashes, backslashes, and equivalent Unicode characters become hyphens, and names that are empty or compare as empty, . or .. receive generated names. The converted name must satisfy the file naming rules.
When uploading items that contain invalid characters, some systems will automatically replace those characters with compatible alternatives. For example, a file named myfile<1>.txt might be renamed to myfile%3C1%3E.txt, myfileU+003C1U+003E.txt, or myfile<1>.txt. This new name is then retained going forward.
Systems that don't support automatic encoding or transcoding of these restricted characters will fail to upload the item and provide a failure message.
Files.com allows you to upload to various types of Remote Server so bear in mind that an upload that succeeds for one type of Remote Server may fail for another type due to each one having different character restrictions.
The type of client, or app, being used to upload can also have an effect. Web browsers usually encode restricted characters during an upload. Different FTP, SFTP, and WebDAV clients will handle encoding or transcoding restricted characters differently. An upload with one client, or app, may succeed but may fail when using another.
Downloading
When downloading items that contain invalid characters, your local system will determine which characters are restricted. Windows, Mac, and Linux each have their own lists of restricted characters so a download that succeeds on one may fail on another.
The type of client, or app, being used to download can also have an effect. Web browsers usually encode restricted characters during a download. Different FTP, SFTP, and WebDAV clients will handle encoding or transcoding restricted characters differently. A download with one client, or app, may succeed but may fail when using another.
Rename files and folders to remove or replace any restricted characters prior to downloading.
Sync
When a Sync is used, Files.com rejects destination names that do not meet its naming rules, and a remote destination can impose additional restrictions. A name that exists on the source system can therefore fail at the destination. Retrying with the same invalid name produces the same failure. Check the logs and rename the affected files or folders on the source system before retrying.
Automations with Remote Server Mount
When using an automation to move or copy items to a location that resides in a Remote Server Mount, the remote server may reject any file or folder that contains restricted characters in their names. Rejected files, which couldn't be stored by the remote system, will fail for this Automation, and all following runs of the Automation, until the restricted character is removed or replaced in the file name. Check for error messages in the logs and rename any failed items to remove, or replace, any restricted characters before re-running the automation again.
ZIP Extraction and Restores
ZIP extraction rejects entries whose destination names are invalid and continues extracting valid items. Rename the affected files or folders within the archive and recreate it before retrying extraction.
Restores also validate the destination names. An item with an invalid name is reported as a failure while other valid items continue restoring. A name's presence in previously stored data does not make it valid for restoration.