I have a Con() statement that creates two "extra" scratch files during it's processing, but that do not get cleaned up once the operation is over and the output is saved.
r=arcpy.sa.Con(elv, rCtypeAlpine, rCtype, 'VALUE > 10000') r.save('covtypeprms_a')
prior to saving
r, I can see that there is also a scratch file for that object. This gets renamed with
r.save(). But I'm still left w/two directories (grids?).
I've been finding and deleting them using
arcpy.ListRasters('t_t*'), which works, but this is really just a hack. Lock files seem to get left behind with this approach. I've also tried
del r to get rid of the handle, but not destroy the copy on disk ('covtypeprms_a').
Why are these appearing and is there more precise way to reference these intermediate objects (so's I can delete them!)?
update on enviroment
product: Desktop 10.1 sp1 OS: Win7 Enterprise sp1
python: Enthought 32-bit in use via Wing IDE
sys.executable yields 'C:\Users\joeblow\AppData\Local\Enthought\Canopy32\User\Scripts\python.exe'
arcpy.env.scratchWorkspaceare both set to the same directory and that all inputs except for the
elvraster are local. This is in 10.1, too. Both the rasters have the exact same properties of min, max, mean, std in the values, fwiw.
Con()example produces multiple scratch files, their solution doesn't clean everything up.
os.remove()even after the scratch grids are destroyed, and even after
del arcpy. It's like the python process itself owns the lock. They disappear when I close my IDE (WingIDE).
del rin my write-up. Was trying to release the handle and allow python to remove the *.lock file even if the grid persisted. Didn't work. 2) Certainly the bug isn't an exact match, but figured since the same compile of arcpy would be running in both places (my IDE and my ArcDesktop python prompt), it was likely related. Environment details posted to original question.