Worksharing (no plugin)

Revit, SolidWorks, and many CAD/BIM tools already take a native operating-system lock on the central model while someone has it open - they open the file for writing and deny write-sharing to everyone else. On a plain network drive that lock only means something on one machine. Swarmfile honors and enforces that native lock across every Windows machine on the drive, so two people can't open the same central model for editing at once - with no add-in and no separate lock server.

Because it works at the filesystem level, not inside the application, there's nothing to install into Revit or SolidWorks. The app takes the lock it always takes; Swarmfile makes it real across every Windows machine on your team. (This enforcement is Windows-only - see Platforms.)

How it works#

When a native application opens a file on the mounted drive for writing while denying write-sharing - an exclusive open - Swarmfile registers a short-lived claim on that file for your machine. While that claim is live:

• Anyone on another machine who opens the same file the same way is refused. On Windows the open fails with a sharing violation, which the application surfaces the way it always does - "the file is in use," "could not open for writing," or the app's own central-model-locked message.
• The claim is renewed automatically for as long as the file stays open, so a model left open all day - or overnight - keeps enforcing. When the app closes the file, the claim is released and the next person can open it.

This is the same model a native app uses locally, extended across the internet. You don't change how you work: open the central model, and if someone else has it, your application tells you - just like it would on a shared drive that actually enforced the lock.

Who has it open#

When your open is refused, Swarmfile also raises a notification in the Desktop App naming who holds the file and on which machine, so you're not left guessing at a bare "file in use." The dashboard's Presence view shows the same "who has this open" picture across the team.

Platforms#

Native exclusive-open enforcement is a Windows capability, because the "open for write, deny write-sharing" semantics it builds on are a Windows filesystem concept - and Revit and SolidWorks are Windows applications. A cross-machine exclusive open is enforced between Windows machines.

macOS and Linux mounts don't take part. An exclusive open on a Mac or Linux mount registers no claim, and a Mac or Linux machine opening a file that a Windows machine holds exclusively is not refused by this mechanism. If a file is edited from mixed platforms, use an explicit checkout lock instead.

For teams whose work spans macOS and Linux - the linked assets around a model, or a Rhino/QGIS/IFC ecosystem - the cooperative entry locks and byte-range locks below work on every OS.

When the hub is briefly unreachable#

By default, worksharing fails open: if the network blips at the exact moment you open a file and the claim can't be registered, Swarmfile allows the open rather than blocking every editor whenever connectivity hiccups. Enforcement degrades to advisory for that moment and resumes as soon as the hub is reachable again.

Sites that would rather refuse an edit than risk two people writing the same file during an outage can reverse this. Set the environment variable SWARMFILE_WORKSHARING_FAIL_CLOSED=1 for the engine on each Windows machine, and a claim that can't reach the hub denies the open instead. This is a per-machine setting; the default (off) suits most teams.

The three layers of locking#

Worksharing is the top layer of Swarmfile's locking; each layer answers a different need. From coarsest to finest:

1. Native exclusive-open enforcement (this page). Whole-file, automatic, no plugin, Windows-only. The app's own "open the central model" is the lock. Best for Revit/SolidWorks-style worksharing where opening the file is checking it out.
2. Entry locks. Two related kinds. The automatic entry lock is the 60-second, heartbeat-renewed claim an open file takes while an app has it - nothing to manage. An explicit checkout lock is one you take yourself with swarmfile lock (7 days by default, up to 30), a Pack & Go reservation, or a git lfs lock; both kinds have a "request unlock" flow (swarmfile unlock-request from the CLI). Best when you want to reserve a file you aren't holding open in an app. On a project used as a git-LFS server the entry lock is the same server-side lock as a git lfs lock, so the two mutually exclude across surfaces - and files that live only in git (never written to the drive) get an equivalent path-keyed lock so git lfs lock/unlock/locks still work for them.
3. Byte-range locks. Element-level locking within a single file - the way a BIM tool locks just the elements one person is editing without locking everyone out of the model. This is a lower-level API a native-app plugin calls directly; the swarmfile-brlock CLI is the reference client.

Most teams never touch layers 2 and 3 for worksharing - opening the model is enough.

What this is not#

Worksharing enforcement is a write lock, not a merge system. It stops two people editing one central model at once; it does not merge two divergent copies of a model back together (native BIM/CAD merge is the application's job). For versioning the model over time - branching a design option, rolling back a bad save - see Version Control and Branches & Merging.