Anyone Else Seeing an Explosion of *_gdal.sqlite Files in %TEMP%

[JoshuaBixby]

I recently re-imaged a PC to Windows 10 x64 Enterprise Edition.  After re-imaging, I installed ArcGIS Pro 2.0.1 and no other ArcGIS Desktop components (ArcMap, ArcCatalog, etc....).  Sometime after a week or so of installing Pro, I noticed thousands and thousands of *_gdal.sqlite files in my %TEMP% folder.

I cleaned up my temp files and just figured it was tied to the install.  Within 48 hours, I had ~2,500 files back, and I never even launched ArcGIS Pro in that 48 hours!  I tracked the files down to the ArcGISIndexingServer.exe process.  I know there have been some memory-usage issues with that process, FAQ: Why does the ArcGISIndexingServer.exe use a high amount of computer memory? , but I haven't seen others talking about this issues.

The fact that this is a newly re-imaged machine with a clean install of ArcGIS Pro is what has me scratching my head.  My machine is about as default as it ever will be, so I want to understand why either the process needs to create so many temp files or why it doesn't clean up after itself.

If others check their %TEMP% directories, how many *_gdal.sqlite files are there?  If there are some, how many have been generated in the past day or so?

Thanks, Joshua

[JohnSobetzer]

I just noticed hundreds of these files being generated after installing 2.1.  They weren't there with 2.0.1.  They keep coming even though I have turned off indexing for Pro.  If I end the ArcGIS Indexing server task they stop but if I start Pro and then close it, even without doing anything the task will start up again.  I renamed the indexing exe file in the bin folder and that finally seems to have stopped it for good.  It does seem to involve Excel files.

[KoryKramer]

The bug cited by Joshua above has not been resolved yet.  Unfortunately we'll still see the behavior in 2.1.

The responsible team is aware of the issue (through the bug) and they are working on a fix.

Thank you.

[KoryKramer]

John Sobetzer‌ Joshua Bixby‌ It looks like the team has this fixed in the Pro 2.2 code.  We might (no guarantees) be able to get it in a patch before then so keep an eye open for Pro updates.

[JoshuaBixby]

Thanks for the upates.

[KoryKramer]

You're welcome.

[deleted-user-sYHsW3p_gN5o]

Kory, thanks for looking into this. Do we have any idea as to when 2.2 (or a patch for 2.1) will be releasing? I also have been having this issue.

[KoryKramer]

June is a reasonable estimate for the 2.2 release.  I believe that there will be a second patch for Pro 2.1 in March but I am not able to say whether this fix will go into that patch.

[deleted-user-sYHsW3p_gN5o]

Hmm, okay. I appreciate the response, and I know the dev teams must be working hard and have a lot to do. But is there a workaround to prevent these files being created? Because my computer spent hours deleting these files that were created in only a month or so.

[KoryKramer]

Sorry, Andrew.  There is not a listed workaround.  It is just something that needs to be fixed.  I guess since it is something that is now known, you could go to that folder and delete the files every Friday afternoon (or something like that) before there is too much buildup...  Again, I apologize for the inconvenience, hopefully we can get the fix in a patch before the 2.2 release.

[ThomasColson]

If you can get IT to let you use a domain service account, write a batch file to delete them, and run it nightly as a scheduled task. If you can't get a service account, set the task to start when you login.