- Docs
- Files & Folders
- File System Semantics
- Case Sensitivity
Case Sensitivity
Our research has found that the majority of business-to-business exchanges expect that filenames are treated on a case-insensitive basis, and we've found in practice that it is very common for the two sides of a business-to-business file transfer to disagree on the case conventions for a filename. For example, many EDI systems use all capital letters in filenames, and many others use all lowercase letters.
As a result of this, paths in Files.com are case-insensitive and accent-insensitive. Case differences and accent marks are discarded when comparing filenames for equality.
For example, Files.com will treat these file names as being identical to each other:
filename.txt
FILENAME.TXT
FiLeNaMe.TxT
FÎŁĘÑÂMÉ.TXT
Fïłèńämê.Txt
This means that uploading FILENAME.TXT
to a folder that already contains filename.txt will cause filename.txt to be overwritten by FILENAME.TXT
, or FILENAME.TXT
to be renamed to FILENAME_2.TXT
, depending on how your Overwrite behavior setting is configured. This also applies to any Remote Syncs and Automations that move, copy, or sync, files and folders with Files.com.
Despite being case-insensitive, Files.com is case-preserving, meaning that the path name will use the capitalization and accent marks associated with the original file or folder name.
Our behavior is similar to the default path behavior on Windows, which is still the dominant environment for most enterprises. Our behavior differs from popular "object" storage services such as Amazon S3, which typically use strict binary matching for object names.
The exact algorithm we use to compute path equivalency is documented in the page on Unicode Normalization.
Effects of Case Sensitivity when using Remote Servers
When using a Remote Server Mount, including an automatic mount of a Remote Server (such as browsing a Remote Server in the UI), the case sensitivity behavior of that Remote Server is followed by Files.com to the extent necessary to maintain compatibility with the remote system.
For example, a Remote Mount to Microsoft Sharepoint, Box, or Dropbox, will behave similarly to Files.com because those system are case insensitive, like Files.com.
However, systems like Microsoft Azure Blob, Amazon S3, Google Cloud Storage, and many remote SFTP servers are case sensitive.
We make a best effort to harmonize inbound paths even when working with such remote systems, however this is not always possible. Be sure to always use correct casing in API calls and other integrations, such as Automation configurations, when working with these sorts of remote systems.
Additionally, when copying moving or copying files from a sensitive system to a case insensitive system (including Files.com itself), directories may end up combined or files overwritten.
Case Sensitivity By Remote Server Type
Remote Server Type | Case Sensitive | Unicode Sensitive |
---|---|---|
Amazon S3 | Y | Y |
Backblaze B2 | Y | Y |
Box | N | Y |
Cloudflare R2 | Y | Y |
Dropbox | N | Y |
Files.com | N | N |
FTP | * | * |
Google Cloud Storage | Y | Y |
Google Drive | Y | Y |
Linode (Akamai) | Y | Y |
Linux OS | Y | Y |
Microsoft Azure Blob | Y | Y |
Microsoft Azure Files | Y | Y |
Microsoft OneDrive | Y | Y |
Microsoft Sharepoint | N | Y |
Microsoft Windows OS | N | Y |
Rackspace Cloud Files | Y | Y |
SFTP | * | * |
Wasabi | Y | Y |
WebDAV | * | * |
When connecting to Remote Servers using SFTP, SFTP, or WebDAV, the case sensitivity and unicode sensitivity is determined by the remote server's operating system (OS).