File Locks

When people or applications edit separate copies of the same file, saving one copy can overwrite changes made in another. Files.com provides file locks so applications can record that a file is in use and coordinate their work before changing it.

File locks are advisory. Applications that honor a lock avoid conflicting changes, but the lock does not automatically stop other clients from reading, replacing, moving, or deleting the file. Folder permissions still determine who can perform those actions. Choosing clients that participate in locking matters when several people or systems work with the same files.

Applications That Honor Locks

The Files.com Editor, enabled by default on Files.com sites, honors locks when editing documents, spreadsheets, and presentations. Its lock coordinates editing with other applications so separate editors do not save different copies over one another.

Online co-authoring lets several people edit together in the Files.com Editor. The lock covers their shared session, so colleagues can continue collaborating within it while other participating applications treat the document as in use.

The Desktop App in Mounted Drive Mode also honors these locks for Word, Excel, and PowerPoint files. If someone is editing a document in the Files.com Editor, a desktop application opens that document as read-only. While the document is open for editing through the Desktop App, the Files.com Editor prevents a separate editing session from starting.

Other clients, such as WinSCP, Mountain Duck, and FileZilla, do not honor these locks. They can change a document while someone is editing it through a participating application. A custom application can participate through the Locks API, but it must check and honor existing locks and maintain its own lock while working. Using the file API alone does not provide this coordination.

Exclusive and Shared Locks

An exclusive lock prevents another application from obtaining a conflicting lock on the same path. A shared lock allows other shared locks on that path. Shared locks support coordinated work by several participants, but do not combine their file changes; the application or editing integration must handle that collaboration.

A lock can cover an individual file or a folder. A folder lock can also cover its descendants, so a file can be covered by a lock on a folder above it. The scope tells participating applications which files are in use.

These advisory locks are separate from the Lock Subfolders folder setting. That setting restricts changes to folder structure, such as renaming or moving a folder. It does not coordinate edits to file contents.

Lock Ownership

A lock belongs to the identity that creates it. A person working through their Files.com account creates locks under that account. An integration using a site-wide API key can create locks without an individual user as their owner. A lock therefore does not always identify one person who has a document open.

By default, another ordinary user cannot renew or release a lock merely because they can edit the file. The creator retains that control, while Site Administrators and integrations authenticated with a site-wide API key can also manage the lock. Creating, renewing, and releasing locks require write permission at the covered path.

An application can allow other users to renew or release its lock. With that policy, users from the same site or its parent site can manage the lock if they have write permission at the path. This lets an application maintain a shared editing session on behalf of several people. The choice is independent of whether the lock is exclusive or shared: allowing shared locks does not by itself let another user end an existing lock.

When visitors edit through a Share Link in the Files.com Editor, the editor maintains the lock for the shared session. Visitor registration does not give the first visitor exclusive control of the lock. Other visitors with permission to edit can join the same session, with the editor managing the lock on their behalf.

Lock Lifetime and Expiration

An application releases its lock when its work finishes. Locks also have an expiration time so a closed application, interrupted connection, or abandoned session does not leave a file marked as in use indefinitely.

The default timeout is 12 hours. An application can choose a different timeout and renew the lock while work continues. Each renewal starts a new timeout period from the time of renewal, so 12 hours is not a fixed limit on the total length of an editing session.

If an application stops maintaining a lock without releasing it, the lock remains active until its timeout passes. Expired locks no longer appear as active locks or reserve the path for participating applications. An application resuming after expiration needs to check for other active locks and acquire a new one before continuing; another application may have begun work in the meantime.