-
-
Notifications
You must be signed in to change notification settings - Fork 0
File Locking
Anchor LFS implements the Git LFS File Locking API, allowing teams to coordinate concurrent edits on binary files that cannot be merged (e.g., images, 3D models, game assets).
File locking lets a user declare exclusive edit access to a file. Other users can see the lock and avoid making conflicting changes. Locks are advisory. They don't prevent Git operations, but Git LFS clients warn when pushing changes to locked files owned by someone else.
git lfs lock assets/model.bingit lfs locks# Unlock your own lock
git lfs unlock assets/model.bin
# Force unlock (override another user's lock)
git lfs unlock --force assets/model.bingit lfs locks --verifyThis shows locks separated into "ours" (your locks) and "theirs" (other users' locks), helping you identify potential conflicts before pushing.
Locks are stored as JSON files on the local filesystem, regardless of the configured storage backend:
<data_directory>/locks/<endpoint>/locks.json
Each endpoint has its own lock file. The lock store uses an in-memory cache that validates against the on-disk file's modification time and size to detect external changes.
Each lock record contains:
| Field | Description |
|---|---|
id |
Unique identifier (UUID format) |
path |
Relative file path within the repository |
locked_at |
ISO 8601 timestamp of when the lock was created |
owner.name |
Username of the lock owner |
Lock ownership is determined by the authenticated user:
- GitHub authentication: The lock owner is the GitHub username associated with the Personal Access Token
-
No authentication: The lock owner is the Basic Auth username if provided, or
"anonymous"if no credentials are sent
Only the lock owner can unlock a file, unless the force flag is used.
Lock list and verify responses support cursor-based pagination:
- Default limit: 100 locks per response
- Maximum limit: 1000 locks per response
- The response includes a
next_cursorfield. Pass this value as thecursorquery parameter in the next request to fetch the next page. - An empty
next_cursormeans there are no more results.
Lock paths are validated to ensure security:
- Must be valid relative paths
- Cannot contain path traversal sequences (
..) - Cannot be absolute paths
- Cannot contain null bytes or other unsafe characters
- API Reference: Full locking API details
- Git LFS Client Setup: Client configuration
- Authentication: How lock ownership ties to authentication