<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic arcgisruntime_* Temp space not deleted in ArcGIS Runtime SDK for WPF (Retired) Questions</title>
    <link>https://community.esri.com/t5/arcgis-runtime-sdk-for-wpf-retired-questions/arcgisruntime-temp-space-not-deleted/m-p/334431#M1663</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Hello -&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Fairly frequently, the arcgisruntime_* temp space is not fully deleted.&amp;nbsp; This doesn't always happen.&amp;nbsp; It seems to be based on some timing, and there seems to be a &lt;/SPAN&gt;&lt;STRONG&gt;*.gdb\timestamps&lt;/STRONG&gt;&lt;SPAN&gt; file which is often the troublemaker.&amp;nbsp; An Access Violation happens when the runtime tries to delete this file.&amp;nbsp; Using Procmon we can see that after the access violation, another process eventually closes its access to this file.&amp;nbsp; So if the delete happened later, it would have been fine.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Oddly, this seems to only happen when we proactively stop our services.&amp;nbsp; We loop through each LocalService, and call the synchronous Stop() method.&amp;nbsp; After all are stopped, we call Shutdown() on the LocalServer.&amp;nbsp; If we don't do any of these proactive stops, the cleanup seems to finish every time.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Is this a known issue?&amp;nbsp; Is it possibly fixed in 10.1.1?&amp;nbsp; Is the suggestion to simply not proactively shut down the services?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;-Brian&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 06 Mar 2013 15:21:57 GMT</pubDate>
    <dc:creator>BrianRassier</dc:creator>
    <dc:date>2013-03-06T15:21:57Z</dc:date>
    <item>
      <title>arcgisruntime_* Temp space not deleted</title>
      <link>https://community.esri.com/t5/arcgis-runtime-sdk-for-wpf-retired-questions/arcgisruntime-temp-space-not-deleted/m-p/334431#M1663</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Hello -&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Fairly frequently, the arcgisruntime_* temp space is not fully deleted.&amp;nbsp; This doesn't always happen.&amp;nbsp; It seems to be based on some timing, and there seems to be a &lt;/SPAN&gt;&lt;STRONG&gt;*.gdb\timestamps&lt;/STRONG&gt;&lt;SPAN&gt; file which is often the troublemaker.&amp;nbsp; An Access Violation happens when the runtime tries to delete this file.&amp;nbsp; Using Procmon we can see that after the access violation, another process eventually closes its access to this file.&amp;nbsp; So if the delete happened later, it would have been fine.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Oddly, this seems to only happen when we proactively stop our services.&amp;nbsp; We loop through each LocalService, and call the synchronous Stop() method.&amp;nbsp; After all are stopped, we call Shutdown() on the LocalServer.&amp;nbsp; If we don't do any of these proactive stops, the cleanup seems to finish every time.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Is this a known issue?&amp;nbsp; Is it possibly fixed in 10.1.1?&amp;nbsp; Is the suggestion to simply not proactively shut down the services?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;-Brian&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 06 Mar 2013 15:21:57 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-runtime-sdk-for-wpf-retired-questions/arcgisruntime-temp-space-not-deleted/m-p/334431#M1663</guid>
      <dc:creator>BrianRassier</dc:creator>
      <dc:date>2013-03-06T15:21:57Z</dc:date>
    </item>
  </channel>
</rss>

