File System Semantics is a cloud-based filesystem that is designed for business and automation use cases.

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

This means that 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 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

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

When accessing 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 is a case-insensitive file system, meaning it behaves more similarly to Windows and Mac than Linux.

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

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, 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, as this can be a security concern.

However, some applications, such as file synchronization apps, require the ability to set the File Modification time. offers a feature that enables this capability. If you wish to enable user-provided modified times in, 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.

In POSIX-based filesystems and in NTFS, you can create pointers to files via hard links or symbolic links. Windows calls these Shortcuts. 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 such operations will fail if the destination already exists, preventing the existing file from being overwritten.

Atomic Uploads treats file uploads as atomic (i.e. "all or nothing") operations. In other words, a file must be uploaded to 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 web interface and's native apps like our Command Line App (CLI)Desktop App for Windows/MacMobile 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 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 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 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 from a remote server if the filename is valid on the remote but not on For example, remote filenames ending in a space character or containing a slash character are not allowed on This scenario will result in failures appearing in Sync logs.

Get Instant Access to

The button below will take you to our Free Trial signup page. Click on the white "Start My Free Trial" button, then fill out the short form on the next page. Your account will be activated instantly. You can dive in and start yourself or let us help. The choice is yours.

Start My Free Trial

©2022 All right reserved


  • Start My Free Trial
  • Pricing
  • Docs
  • API and SDKs
  • Contact


(800) 286-8372


9am–8pm Eastern