topic Temporary raster - what if TEMP/TMP is readonly? in ArcObjects SDK Questions

Temporary raster - what if TEMP/TMP is readonly?

KeithOlson — Mon, 20 Jun 2011 22:20:52 GMT

I'm developing a tool in VB.Net that involves some raster processing using temporary datasets for the intermediate steps. Typically, ArcMap does this by storing the temporary rasters in the folder specified by the system TEMP or TMP variables. These temporary rasters go away automatically when they are no longer referenced or when I release the objects in code. Everything works perfectly fine according to ArcObjects documentation. That is, unless the value of TEMP/TMP points to a folder that is not writeable by the user.

For example, I have a user with TEMP/TMP set to "C:\Program Files\ArcGIS\Bin" (which I'd advise against, but that's a different story). When the user runs my tool, ArcMap cannot save the temp rasters to that location and the tool crashes.

Is there a better way to handle temporary rasters? I've seen some sample code that uses a hardcoded "C:\temp" location, but I don't think that's the best practice either.

thanks for your help,
Keith

Re: Temporary raster - what if TEMP/TMP is readonly?

KeithOlson — Sat, 11 Dec 2021 09:10:11 GMT

After some more digging, I found out that the user does have the TEMP variable set to a writeable folder. However, the error message they get includes this:

System.Runtime.InteropServices.COMException: ("esriDataSourcesRaster.GdalDriver") Failed to copy raster dataset
ERROR 010240: Could not save raster dataset to C:\Program Files\ArcGIS\Desktop10.0\Bin\C:\Program Files\ArcGIS\Desktop10.0\Bin\ras44 with output format GRID.

So, why would it be trying to save to that location if the TEMP variable points to a different location?
(Also, strange error message with the duplicated folder path. Not sure what the deal is there...)

Anyway, here's the piece of code that leads to the exception:

Dim pClipDataset As IGeoDataset = Nothing
Dim pTransOp As ITransformationOp = New RasterTransformationOp
Dim pEnv as IEnvelope = New Envelope
pEnv.PutCoords(pUTM_xmin, pUTM_ymin, pUTM_xmax, pUTM_ymax)   'variable values set earlier
pClipDataset = pTransOp.Clip(CType(pSelectedRaster.Raster, IGeoDataset), pEnv)  'pSelectedRaster is an IRasterLayer object defined earlier

Again for most users this works just fine. But for the one user it fails and gives the error above.

Re: Temporary raster - what if TEMP/TMP is readonly?

KeithOlson — Wed, 22 Jun 2011 16:17:04 GMT

Update:
The user has been able to get the tool to work on their machine with other input rasters. So, we are chalking this one up as something quirky going on with that one raster. The unsettling thing is that we cannot reproduce the error on any other machine even using the raster in question. We're putting this one to bed for now and moving forward, but if anyone has any other ideas or plausable explanations, it would still be appreciated.

Re: Temporary raster - what if TEMP/TMP is readonly?

KenBuja — Thu, 23 Jun 2011 14:35:35 GMT

In my VB.NET application, I've used a scratch workspace to store the temporary files. Here's the help information about creating them.

Re: Temporary raster - what if TEMP/TMP is readonly?

KeithOlson — Thu, 23 Jun 2011 18:05:59 GMT

Ken, thanks for that link. Next time we generate a new build, I'll look into that some more. Might be worth a try and perhaps better than messing with the system variable.

Re: Temporary raster - what if TEMP/TMP is readonly?

KeithOlson — Wed, 12 Sep 2012 16:29:15 GMT

Finally solved this one. For anyone interested, we actually discovered that the problem was due to the user's regular temp space (C:\Users\<username>\AppData\Local\Temp) being filled up. ArcGIS uses the same temp folder as many other applications, so if proper garbage collection is not performed or if apps using that temp space crash, etc. the temp files get left behind. Over time the folder will fill up to its allocated limit. When this happens, ArcMap detects that the folder is full and moves on to the next location it thinks might be good to store temp files, which in our case was in C:\Program Files... which the user is not allowed to write to.

We had the user manually empty his temp folder and then the tool ran successfully.

So, our solution then was to catch the exception and give the user a message that his temp folder is full and that they need to delete files there before proceeding. We also noticed that ArcMap does not delete scratch workspaces upon exit like it does other temp data, so we went ahead and added code to delete all scratch workspace files when the tool is finished.