File geodatabase, freelist file locks

[BruceCarroll]

We have a process that routinely exports datasets from Oracle SDE (copy_management) to a file geodatabase.
During this process the geoprocessing environment is set to overwrite outputs of geoprocessing operations.
 
When a dataset within a file geodatabase is set to be updated through the copy_management tool sometimes the script errors
and the error message reports it is because the dataset is being accessed by another application; I am positive
this isn't the case.  I think the error is because of how the "freelist" file is created in the file geodatabase.  This
error seems to occur only when the SDE dataset being copied out is part of an ArcGIS Server service.  I think
this blocks the deletion of an existing dataset while executing the copy_management tool that should overwrite
it.  I am able to overwrite a dataset successfully within a file geodatabase by using the copy_management when
the SDE dataset is not part of an ArcGIS Server service.

Other than simply deleting the freelist files (a risky thing to do, but it works because I tested it) prior to executing copy_management, how may I erase/clear the "freelist" files, or is there another solution?  Dropping the ArcGIS
Server service or rebooting the server is not an option.

Thank you,
Bruce

[LanceShipman]

The existence of a freelist will not block anything. Are there any .lock files present? If server is running there should be.

[DavidSousa]

I don't think the existence of .FREELIST files has anything to do with your problem.  However, the way to get rid of .FREELIST files is to run the Database Compact command.  It would be a bad idea to simply delete them, as you will never be able to recover the unused space in your datafiles.

If you are getting an error message that another process is accessing your dataset, that can be considered to be a reliable message.  Why are you so sure that no other process is active?  The way to know for sure is to go into the database folder and look at any .LOCK files that are present.  In the lock file names, you can see the name of the locked dataset, the type of lock, and the process and thread ID which owns the lock.  You will probably find that some other process does in fact have the dataset open.

[TomMagdaleno]

I am having a similar problem where timestamps and other files won't delete when I try to delete and replace a file geodatabase.  I have to copy and paste data from one geodatabase to another in Windows Explorer.  This didn't happen before it was part of ArcGIS Server.

[DavidSousa]

Using Windows Explorer to copy your data while it is in use by another process is very risky.  There is a very good chance that you will end up corrupting your data in some way.  The problem is that any files that are open might not be copied as expected and you will end up with files missing in the new folder.  It used to be the case that Windows Explorer would give you an error message that there was a sharing violation and the copy would stop.  But that behavior was changed in Vista and Windows 7.  Now, it quietly copies the files it can, and skips the files that cannot be copied.

I hope you have good backups!

It is also extremely risky to go into the database folder and delete files that are there.  Please make backups first!

[BrianLott]

Hi Bruce. I'm seeing the exact same behavior as you reported. I have an application that exports data to a file geodatabase and then zips it up to make the database downloadable. The process replicates functionality from a desktop version of the application, so I can verify that the exact same code that works in desktop fails in server because a .freelist file is being held open in server (I suspect by an ArcSOC.exe service).

Have you had any success in solving this issue?

Thanks,

Brian

[MichaelVolz]

To bypass the locks that are placed on the file geodatabase by ArcGIS Server you should use a DeleteFeatures_management call followed by an Append_management call.  The Copy_management tool copies the schema which is locked, but the schema is not touched when using DeleteFeatures_management followed by Append_management.  I ran across this issue years ago and have used Delete and Append for years without any issues with file gdb locks.