File System Semantics

The Files.com file system presents files and folders in a single tree, including files in native Files.com storage and files accessed through Remote Server Mounts. Files.com defines the rules for paths, names, permissions, timestamps, and file operations within that tree.

This page describes how that file system works, including how its rules apply to mounted storage. Transfer selection, scheduling, and workflow settings belong to Syncs and Automations and are covered in their own documentation.

Permissions

Files.com controls access through folder permissions assigned to users, groups, or Partners. These grants determine which actions a user can perform on a folder and its contents.

Files.com permissions are independent of Windows NTFS permissions and UNIX/POSIX permissions. FTP, SFTP, or WebDAV clients may display POSIX permission values in a folder listing for compatibility. Those values do not describe the user's actual access; use Files.com folder permissions to manage access.

Transfer URL Expiration

Files.com uses signed URLs to authorize individual uploads, downloads, and previews. These temporary URLs let file data move efficiently without repeating a full permissions check for every request. This improves transfer performance for everyone using the service, with a delay before a permission change takes effect for URLs that have already been issued.

These periods start when the URL is issued and apply to native Files.com storage, Remote Servers, and the Files.com Agent. Each URL authorizes a particular operation; it does not grant general access to the site. Treat the complete URL as sensitive.

Generated preview assets and previews of original files in native storage use 3-hour URLs. Previews that access an original file directly on a Remote Server or through the Files.com Agent use the shorter download URL lifetime.

Removing someone's access to a file prevents them from obtaining new transfer URLs for it. A URL they already have remains usable until it expires. They can therefore start a new download request for up to 3 minutes after access is removed, an upload request for up to 15 minutes, or a preview request for up to 3 hours. The remaining window is shorter when the URL was issued before the permission change.

URL expiration limits when a request can start. It does not necessarily terminate an upload or download already in progress: a transfer accepted before expiration can continue afterward. Revoking permissions or expiring a URL also cannot retrieve content the person has already downloaded or loaded in their browser. This distinction matters when planning offboarding or reviewing access controls; the URL lifetime is not a deadline for stopping all file data in transit.

Clients should request URLs when they are ready to use them. If a URL has expired, request a new one through Files.com; access is checked again. For multipart uploads, request a URL for each part through the upload API. Reopen an expired preview to request fresh access. These URL lifetimes are separate from login session timeouts, file retention, and the expiration date of a Share Link.

Folder (Directory) Separation

Files.com represents paths with one forward slash (/) between each folder and the next part of the path, as in Customers/Acme/invoice.pdf. Its normalized paths have no leading or trailing slash and do not contain a backslash (\).

Spaces at the End of Folder Names

Files.com requires folder names to end with a non-whitespace character. A folder name cannot end with a space, tab (\t), newline (\n), or carriage return (\r).

This keeps folder names compatible with file transfer clients and protocols, particularly FTP. Its text-based commands can trim, ignore, or misinterpret trailing whitespace during transfers and directory listings.

Spaces at the End of File Names

Files.com native storage allows file names to end with a space, tab (\t), newline (\n), or carriage return (\r). Remote Server Mounts have additional naming requirements.

Some other operating systems, file transfer clients, and file transfer protocols do not support trailing whitespace in file names. Clients and protocols that don't support it remove or substitute those whitespace characters when transferring or uploading files to Files.com.

No Slashes Inside File/Folder Names

Files.com reserves the forward slash (/) for separating parts of a path, so it cannot appear inside an individual file or folder name. This also keeps paths compatible with Remote Servers that use slashes as folder separators. Other restricted characters apply to file and folder names as well.

Maximum Path Length

Files.com supports paths up to 550 characters long. The limit includes all parent folders, separators, the file name, and its extension.

File Modification Times

Files.com records when a file was uploaded and when its contents were last modified. By default, users cannot edit the modification time, preserving the system's record of when a change occurred.

The File "last modified date" semantics setting lets you use a modification time supplied by the uploading client, such as the date the file was last changed on its source system. Find the setting through the search box at the top of the web interface. Showing the user-provided date affects FTP, SFTP, WebDAV, and the web interface. The API and SDKs provide both the user-supplied timestamp and Files.com's own timestamp of the file's actual most recent modification.

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

• Uploaded: The date and time the file was uploaded to Files.com.
• Modified: The date and time the file was last modified on Files.com.
• Modified on source system: The modification time supplied by the source system during upload. This appears only when the source provided a value that differs from Modified.

No Support for Shortcuts, Hard Links, or Symbolic Links

Files.com stores files and folders without shortcuts, hard links, or symbolic links that point to another file or folder. A path identifies the file or folder at that location; you cannot create a link in the Files.com file system that redirects access to another path.

Move and Copy Overwrites

Files.com preserves an existing destination file when you move or copy another file to the same path, unless you explicitly request an overwrite.

When you request an overwrite, Files.com deletes the existing destination file and then moves or copies the new file into its place. The delete and the replacement are logged as separate actions at the destination.

This sequence applies within native storage, within a Remote Server Mount, and between storage locations. Within native storage, a move changes the file's recorded path, and two files cannot occupy the same path. Within a single Remote Server, the provider performs the operation and determines how it handles an occupied destination. Deleting the destination first gives a requested overwrite the same result across these systems.

Moves and copies between native storage and a Remote Server Mount, or between two Remote Servers, deliver the replacement as an upload. Files.com still deletes the destination first, even when that upload could replace the file in place.

When the destination is on Files.com native storage, the replaced file stays recoverable through Restore Deleted Files and Folders for your site's retention period.

When the destination is on a Remote Server Mount, Files.com sends the delete to the remote server. The account used to connect to that server needs permission to delete the destination file as well as write its replacement. Files.com cannot restore the deleted remote file; recovery depends on the remote system's own versioning or recovery features.

Remote Server Mounts

Files.com applies its file system rules to folders connected through a Remote Server Mount, along with the remote system's own restrictions. File operations inside a mounted folder act on the remote files directly.

File and folder names on a Remote Server Mount cannot end in spaces, even if the remote system accepts them. Names must also satisfy the remote system's character and length restrictions. Creating or uploading an item with an unsupported name produces an error.

Invalid File or Folder Names

Files.com requires names used through a Remote Server Mount to fit both systems' rules. If an operation fails because of a name, rename the item to remove prohibited characters or shorten its path to fit the remote system's limits.

Remote Servers can limit an individual name or the entire path. Common length limits are 160 or 255 characters. Depending on the remote system, the calculation includes the file extension and may also include parent folders or a temporary suffix added during a transfer.

The Files.com 550-character path limit still applies when the remote system permits a longer path.