File System Semantics

---

Files.com is a cloud-based managed file transfer platform that is optimized for business-to-business file transfer.

In general, we've tried to design the semantics of the system so that it "just works" in the majority of business-to-business file transfer needs. Since this domain has been around for a lot longer than Files.com (the first file transfer tools were first built in the early 1970s), we've paid close attention to how major existing software packages work and the general expectation around business-to-business exchanges in the real world.

Internally, Files.com implements a virtual filesystem and all filesystem logic is built into the Files.com application itself. That is, Files.com does not use Windows or UNIX file systems as a model for its path conventions. 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 path names use exactly one forward slash (/) between folders in the path, and never uses a slash at the beginning or end of the path. Path names may not contain a backslash (\).

File and folder names may not end with trailing whitespace characters, such as a space (" "), a tab (" " or "\t"), a new line (\n), or a carriage return (\r).

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. To enable user-provided modified times in Files.com, type File "last modified date" semantics in the search box at the top of every page and click the matching result. Adjust the setting as needed.

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.

When previewing a file online, the following timestamps are shown:

Uploaded - The date and time that the file was uploaded to Files.com.

Modified - The date and time that the file was last modified on Files.com.

Modified on source system - The date and time that the file was last modified on the system that uploaded the file. This timestamp is only displayed if a date and time were provided by the source system during upload and if the time value differs from the Modified time value.

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.

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.

Remote servers will likely prohibit certain characters from being used in file and folder names. If you see issues with invalid file or folder names, we recommend you modify those names.

Remote servers may also restrict the length of the file or folder name. Common length limits are 160 characters or 55 characters.

Bear in mind that some remote servers calculate the total length as being either just the file or folder name, including any extension. Or the sum of the whole folder path + file name + extension + temporary suffix.

To resolve this issue, shorten the name of files and folders so that they are below the length limits of the remote server.

On the Files.com side, the path limit is 550 characters for the sum of the full path, including folder names.