3

I have created a temporary File GDB-based scratch workspace as follows:

var factoryType = Type.GetTypeFromProgID("esriDataSourcesGDB.FileGDBScratchWorkspaceFactory");
var factory = (IScratchWorkspaceFactory)Activator.CreateInstance(factoryType);
var workspace = factory.CreateNewScratchWorkspace();

Running this code creates a File GDB in my user profile's .\AppData\Local\Temp directory.

Esri's documentation claims that:

"Workspaces created by IScratchWorkspaceFactory.CreateNewScratchWorkspace will be automatically deleted when the last reference to them is released."

However, this does not happen. Even after my application terminates, and even though all ArcGIS application have been closed, the File GDB remains in my temporary folder.

I have tried explicitly releasing the workspace:

Marshal.FinalReleaseComObject(workspace);

But that does not delete the temporary File GDB either. Trying to additionally delete the directory will not work either, because some file in the File GDB directory is still in use:

var path = workspace.PathName;
Marshal.FinalReleaseComObject(workspace);
System.IO.Directory.Delete(path, recursive: true);

  1. Am I doing something wrong? And if so, what? How do I best deal with scratch workspaces that are no longer in use?

  2. Is the documentation simply incorrect on this point?

  3. Or will Windows regularly delete that temporary folder and thus delete the scratch File GDB? (This does not seem to be the case.)

  • You describe how you create and try to destroy the scratch workspace but what do you actually do with it? What was going in it? – Hornbydd Sep 1 '14 at 22:23
  • @Hornbydd: Given the official documentation, I don't see why this should matter; but in simplified terms, I'm copying a dataset from an existing File GDB into the scratch workspace using var copy = new ESRI.ArcGIS.DataManagementTools.Copy { … }; Geoprocessor.Execute(copy, …);, then I'm transferring data rows of that copy back into an empty dataset of the original workspace using ObjectLoader.LoadObjects(…);. – stakx Sep 2 '14 at 5:46
  • (These data transfers are obviously not a useful real-world scenario, it is just a simple test / proof of concept. But if that already leads to issues, then any real-world scenario will likely exhibit the same problem.) – stakx Sep 2 '14 at 5:55
  • Just an idea... Have you tried destroying the geoprocessor that may be the object that holds a reference to the workspace? – Hornbydd Sep 2 '14 at 8:18
  • @Hornbydd: I haven't tried exactly that. But, just prior to calling IAoInitialize.Shutdown (called outside the method where I used the Geoprocessor), I have forced a garbage collection, which should release the geoprocessor object and others. Unfortunately, that didn't make a difference, either. – stakx Sep 2 '14 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.