Timestamp File in File Geodatabase (directory)

[JoeBorgione]

As I work through a python project, I'd like to delete a directory that contains a file geodatabase. Using shutil.rmtree(directory_containing_Filegdb) with the mxd still open, I get an Windows error about a file called timestamp in MyFileGeodatabse.gdb that is being used by another process.

A google search of  "file geodatabase timestamp" turns up an article from ESRI Tech Support saying it's okay to remove the lock file but warns not to remove the timestamp file as it will corrupt the file geodatabse.

Warnings?  I don't need no stinkin' warnings....

I can run arcpy.Delete_management(the_file_fgd_workspace) in the python window and it runs without an error. But....  It leaves behind the the"directory" MyFileGeodatabse, along with the timestamp file within it: all the other files associated with what we know as a file geodatabase are gone.

The original premise of this application is to create a directory as well as a file gdb, as a target gdb for a replica.  Once the replica is synced back to the parent, the idea is to delete to whole mess, so the user can move on to another area of interest, re-create the directory and the file geodatabase, create a replica etc, etc.

Surely, I can set the directory and file gdb up a priori, and simply empty the feature classes out of that file geodatabase when the edits are done, but I'd like not to leave anything behind at the end of the day if possible.

[MasaoMatsuoka]

I have experienced the same issue. In my case I have created a C# application that creates a new file geodatabase and copy feature classes into it. It also moves the file geodatabase to another folder. But when it is time to delete the file geodatabase, some files are left behind. I tried to delete them using both Geoprocessing and the OS. Geoprocessing tool says the operation was successful, but some files are left behind. If I try to delete those files in Windows Explorer, it says the files are opened in another application. I looked using the Process Explorer, but could not find any suspects. The application was completely closed, and as far as I could see nothing was holding on the files. However after the PC was rebooted where the app ran, the files became free. So something was holding onto the files. Hopefully someone can shed some light on this.

[JoeBorgione]

Masao Matsuoka‌ -  I bit the bullet and just create the File GDB upon the initial running of the script with an if not exists approach:

path = r"C:\Replicas"
        if not arcpy.Exists(path):
            os.mkdir(path)
        if not arcpy.Exists(r"C:\Replicas\Replicas.gdb"):
            arcpy.CreateFileGDB_management(path,"Replicas.gdb")‍‍‍‍‍

 So the first time it's run it creates the path and FGDB.  At the end of the script I do some house cleaning and delete the feature classes that are created during the replication process; when the user runs it the next day, the path and FGDB are already provided...