File System Semantics

Files.com is a cloud-based filesystem that is designed for business and automation use cases.

Internally, Files.com is implemented as a virtual filesystem and all filesystem logic is built into the Files.com application itself.

This means that Files.com can behave differently from the Windows or POSIX-based filesystems that you are used to. This page lists some of the key differences to be aware of.

Permissions

Files.com uses its own Permissions scheme, which operates differently from POSIX or NTFS permissions. Please see our documentation on Permissions to understand how permissions work in Files.com.

With proper use of Files.com's permissions system, you should be able to achieve any access control scheme you require for your application.

When accessing Files.com through integrations such as FTP, SFTP, or WebDAV, those integrations will sometimes report POSIX permissions when you list a folder. These permissions are dummy values and should be disregarded.

Case Sensitivity

Files.com is a case-insensitive file system, meaning it behaves more similarly to Windows and Mac than Linux. Lower case, upper case, and mixed case are considered identical for both file and folder names.

For example, Files.com will treat these file names as being identical to each other:

• filename.txt
• FILENAME.TXT
• FiLeNaMe.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 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

When using a Remote Mount, the case sensitivity of that Remote Server is used instead of the Files.com case sensitivity.

For example, a Remote Mount to Microsoft Sharepoint, Box, or Dropbox, will be case insensitive while a Remote Mount to Microsoft Azure Blob, Amazon S3, or Google Cloud Storage, will be case sensitive.

Additionally, Files.com has somewhat unique case-sensitivity behavior as it relates to Unicode characters (such as foreign vowels with accent marks, emoji, etc.)

For example, Files.com will also treat these file names as being identical to each other:

• filename.txt
• FÎŁĘÑÂMÉ.TXT
• Fïłèńämê.Txt

Effects of Case Sensitivity when using Remote Servers

When moving or copying files between Files.com and Remote Servers, whether using Remote Sync or an Automation, be aware that each system's case sensitivity will determine if files might be overwritten, or if folders might have their contents merged, based on their insensitive names.

This issue will only occur when moving or copying files from a sensitive system to an insensitive one.

No Spaces at the End of File/Folder Names

Because the FTP Protocol is ambiguous with regard to spaces at the end of filenames, to protect data integrity, Files.com disallows spaces at the end of file/folder names.

No Slashes Inside File/Folder Names

To maintain compatibility with remote servers, which typically use a slash character to delimit folder names, you may not use a slash character inside a specific file or folder name.

Maximum Filename Length

The maximum length of a filename path (including all its parent folders) is 550 characters, including the file extension.

File Modification Times

By default, file modification times are not editable by users in Files.com, as this can be a security concern.

However, some applications, such as file synchronization apps, require the ability to set the File Modification time.

Files.com offers a feature that enables this capability. If you wish to enable user-provided modified times in Files.com, you can adjust the setting at Settings > General > File "last modified date" semantics.

Showing the user-provided date will affect FTP, SFTP, WebDAV and the web interface. For interactions via our API or SDKs, you will get access to both timestamps -- the user set timestamp as well as our timestamp of the actual most recent modification time of the file.

No Support for Shortcuts, Hard Links, or Symbolic Links

In POSIX-based filesystems and in NTFS, you can create pointers to files via hard links or symbolic links. Windows calls these Shortcuts. Files.com does not currently support either hard links or symbolic links.

Destructive Move/Copy

With a POSIX-based filesystem, a move or copy operation can be destructive, overwriting an existing file if the destination already exists. By contrast, in Files.com such operations will fail if the destination already exists, preventing the existing file from being overwritten.

Atomic Uploads

Files.com treats file uploads as atomic (i.e. "all or nothing") operations. In other words, a file must be uploaded to Files.com completely before the file will be shown in file listings and available to work with. This approach is necessary to ensure that a file is never accessed when in an incomplete state, and that file integrity is maintained with automated processes like webhooks, GPG encryption, Automations, and Remote Server Syncs.

This means that any attempts to access a file before the upload has completed will fail as if the file does not exist. If an existing file is being changed, downloading it during a change will result in the previous, unchanged version of the file being downloaded.

While file upload atomicity will be maintained when using the Files.com web interface and Files.com's native apps like our Command Line App (CLI), Desktop App for Windows/Mac, Mobile app for iOS/Android, and SDKs for developers, we cannot guarantee the same for file transfers performed using third party apps such as FTP apps. Therefore, we strongly recommend using Files.com native apps wherever possible.

The ability to treat uploads as atomic is limited by the storage solution being used to upload into when using the Remote Mount feature. For example, when using FTP or SFTP to connect to a Remote Mount, a network disruption between Files.com and the remote system can cause atomic uploads to fail, resulting in a partial or incomplete file being uploaded to the remote system.

Applicability to Remote Server Mount and Remote Server Sync

If you are using our Remote Server Sync or Remote Server Mount capabilities, there may be additional restrictions related to the Remote Server. As a general rule, we will apply restrictions that are applied by Files.com as well as restrictions applied by the remote server.

For example, we will not allow spaces at the end of file/folder names on a Remote Server Mount, even if the remote supports them. We will also not support file/folder names that are not supported by the remote mount. Attempting to do this will result in an error at the time of file creation/upload.

Files may not be able to sync to a remote server if the filename is not accepted on the remote server. This scenario will result in failures appearing in Sync logs. Additionally, files may not be able to sync to Files.com from a remote server if the filename is valid on the remote but not on Files.com. For example, remote filenames ending in a space character or containing a slash character are not allowed on Files.com. This scenario will result in failures appearing in Sync logs.