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.
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.
Files.com is a case-insensitive file system, meaning it behaves more similarly to Windows and Mac than Linux.
Additionally, Files.com has somewhat unique case-sensitivity behavior as it relates to Unicode characters (such as foreign vowels with accent marks, emoji, etc.)
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.
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.
The maximum length of a filename path (including all its parent folders) is 550 characters, including the file extension.
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.
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.
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.
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.
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.
Get Instant Access to Files.com
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