FAQ: Why do file geodatabase .lock files remain after a process is finished?
Why do file geodatabase .lock files remain after a process is finished?
The .lock files remain in the file geodatabase directory after a crashed process, but they do not continue to hold their locks.
The .lock files can only be deleted if the process that created them has exited. An example of a read lock is 'Parcels.TESTPC.7724.1439.sr.lock'. This lock indicates that a process on machine 'TESTPC' is accessing the 'Parcels' feature class from the file geodatabase.
A live lock cannot be deleted. A .lock file may remain in the file geodatabase directory, but does not cause problems when a new lock is placed on the table.
An active lock cannot survive reboot and remain active; the lock file may survive, but it can only be active if a new process creates the lock. Lock file names may be re-used in such instances.
To delete .lock files:
- Use the Compact geoprocessing tool in ArcCatalog to safely remove inactive .lock files from a file geodatabase. Navigate to ArcToolbox > Data Management Tools > File Geodatabase > Compact.
- The .lock files may also be deleted with Windows Explorer, the command line, or other file removal or deletion applications if there are no active processes holding on to the locks.
Warning: Proceed with caution when deleting files other than the .lock files from the file geodatabase directory, as the deletion of certain files can render the database unusable, and requires restoration from backup.
Note: Contact Esri Technical Support for review if rebooting a machine containing the file geodatabase is part of a periodic workflow to clear locks. Ensure a backup of the file geodatabase exists before performing such operations.
- ArcMap: File geodatabases and locking
- ArcMap: Compact file and personal geodatabases
- GeoNet: File geodatabase debugging lock problem, what are .rd and.sr locks?