File locking best practices and specific use case scenarios

File locking functionality allows multiple people to collaborate on the same files/folders without accidentally overwriting each other's edits. However, the locking semantics are largely dependent on the native capabilities provided by the applications based on the opens and/or the location from which the files would be accessed. Resilio recommends the following best practices for file locking in certain use cases and applications. Admins might have to exclude the following file types from file locking to allow seamless simultaneous access.

Revit Central Model scenario
AutoCAD
EPLAN
Rhinoceros 3D
FSLogix

Revit Central Model scenario

How Revit Works with Central Model
A central model consists of a set of files accessed simultaneously by different users while editing local model and when synchronization to central model is triggered. Files’ ranges are accessed/locked.
The project is saved in a *_Backup directory. A user opening the Central Model creates a local copy, typically saved to their Documents folder. Activity is logged continuously in the central *.slog file, which remains open all the time with W:RW access, so others can write to it as well.

Editing of model’s element triggers RW:- access to files in *_Backup directory (users.dat, editingperms.dat, worksetperms.dat, editingrequests.dat, editingdeltas.dat). 

Best practices replicating Central Models by Resilio Agents
The central model (model1_central.rvt in the examples below) is replicated between locations using Resilio Agents in a job with File locking enabled.

Main model is available for reading while being synced with the local model (RW:R lock), so the Agent can transfer the content of the file while it is still being modified.

The .slog file is locked all the time by one of the users on one central location, so users on the other central location can’t write to the .slog file as file locking rejects open requests. Revit silently ignores that.

Exclude the .slog, progress-*.tmp and pulse-*.tmp files along with the Revit_temp directory from locking. To do that, add the following regular expressions (PCRE2 syntax) in the Ignore locks for these files and folders text area in the job's settings.

.slog
Revit_temp
(progress-|pulse-)+.+\.tmp$

Additionally, add *.slog and Revit_temp directory to File and Folder filter.

During sync, if one site updates the central model, the other site's users must wait for Resilio to replicate changes before syncing local model with central. While the message is being presented, Revit retries accessing the files, and once it successfully access files the message disappears and the model is synced correctly.

File locking conflict errors are reported both by Revit and in MC UI:

Locked files during Central model synchronisation in the job look like:

Possible solutions for this synchronization period: 
1. Try synchronizing local model with central model later.
2. Open central model and overwrite local model with the latest version of the central model, latest changes made to local model will be lost
3. Save local model to temporary local model, reopen central model and copy latest changes to central model

AutoCAD

AutoCAD stores all editable drawing data in files with the .dwg extension.  While a drawing may reference external content such as images, fonts, or XRefs, these external files are not modified when the drawing is opened or edited. 

File Locking Model
When a .dwg file is opened in AutoCAD, the application immediately creates two lock files: one with the .dwl extension and another with .dwl2. These files contain metadata including the username of the person who currently has the drawing open. AutoCAD applies a RW:R lock on the main .dwg file and both lock files. This ensures that while the primary user can edit the drawing, others can only access it in a read-only capacity.

Save Process in AutoCAD
Understanding this sequence is important when troubleshooting lock conflicts or data versioning problems.
AutoCAD follows a multi-step save process to reduce the risk of data loss. When a user saves their work, AutoCAD first writes the drawing data to a new temporary file prefix save in its name. Then, the original .dwg file is renamed to a temporary file, which is quickly renamed again to a .bak file, serving as a backup of the last saved state. Finally, the temporary save file is renamed to use the original drawing file name, effectively completing the save operation.

This results in one .bak file being created per save. An example of the file activity during this process might look like the following:

 [16:26:08.799] "Floor Plan.dwg" → "atmpb184d9ef"
 [16:26:10.226] "atmpb184d9ef" → "Floor Plan.bak"
 [16:26:10.242] "saveca59499d.tmp" → "Floor Plan.dwg"

Behavior in Sync Environments
In environments with full file sync, AutoCAD behaves as expected. When a drawing is open on one system, it is correctly recognized as in use by other agents or users, who then access it in read-only mode. This prevents editing conflicts and preserves file integrity.

However, when AutoCAD attempts to work with .dwg files that have not been fully hydrated, the drawing itself might open successfully, but AutoCAD will also try to create and access the associated .dwl and .dwl2 lock files. If these lock files are still in a non-hydrated state or locked due to sync behaviors, AutoCAD may hang or fail to proceed. This is not a limitation of the AutoCAD locking mechanism itself, but rather an incompatibility between shared locks and file hydration timing.
To address it:

• add *.dwl and *.dwl2 to IgnoreList
• remove *.dwg from FileDelayConfig

XRef References in Drawings
Currently, the behavior of AutoCAD drawing files that include XRef (external reference) dependencies has not been tested in this context. Administrators should test such configurations in their own environment before rolling them out at scale, especially when TSS or other sync technologies are involved.

EPLAN

The EPLAN application implements and maintains its own locking mechanism, which conflicts with Resilio's shared file locks feature. As a result, file access issues arise, and eventually, the files become read-only. To mitigate this issue, we recommend excluding the following EPLAN-specific files from the locking mechanism:

• .elk
• .eod
• .eox
• .flk
• .lck
• .slk
• .xlk

To exclude files from locking, add the following regular expression (PCRE2 syntax) to the Ignore locks for these files and folders text area in the job's settings.

\.(elk|eod|eox|flk|lck|slk|xlk)$

Rhinoceros 3D

The application uses .3dm.rhl files to maintain file locking information about the users' information (who, when, and where the file(s) were locked), preventing further file modifications. This is different from the regular file locking behavior

This read-only lock prohibits further file modifications, and subsequently, the existing Rhinoceros file opens will not be visible in the list of Resilio File locks. To view and manage the Rhinoceros file locks from the Resilio Management Console, add the custom parameter shared_locks_strict_access_checks:false to Job Profile.

FSLogix

FSLogix profile locking isn’t compatible with Resilio file locking. Accessing the FSLogix profiles before they are synchronized stalls the sync process, which will not resume until the users stop accessing them.
This is due to the native FSLogix behavior, which only allows read-only access to previous versions of the profile while the new ones are being downloaded from other agents. This leads to a soft deadlock, wherein the Resilio agent is unable to update the profile to the latest downloaded version as it has read-only access to the previous version. To avoid this, Resilio recommends excluding FSLogix profiles from the file locking.