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 may 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 can’t 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:

• One can use the Compact geoprocessing tool in ArcCatalog to safely remove inactive .lock files from a file geodatabase. (In ArcToolbox under 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.

Please 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.

Please contact Esri Technical Support for review if rebooting a machine containing the file geodatabase is part of a periodic workflow to clear locks. Ensure that a backup of the file geodatabase exists prior to performing such operations.