ThinkGeo.com    |     Documentation    |     Premium Support

EcwRasterLayer - file is locked after closing

#1

I'm using version 5.0.0.0 of the services edition to prototype at the moment.  In testing some of the prototype functionality which checks to see if the server application can open a raster layer (in this case an ECW) the file does not seem to be unlocked when the layer is closed. 


In regard to the below code, have I missed anything?  RasterLayer etc don't inherit from IDisposable so that's not an option.  We'll be doing this same sort of thing with a number of other raster layer types as well. 


The below code exhibits the issue:




public void TestLockedFile()
{
var filePath = Path.Combine(m_currentPath, Guid.NewGuid().ToString() + ".ecw");

try
{
File.WriteAllBytes(filePath, Resources.testECW);

var layer = new EcwRasterLayer(filePath);
}
finally
{
File.Delete(filePath); // this works fine
}

try
{
File.WriteAllBytes(filePath, Resources.testECW);

var layer = new EcwRasterLayer(filePath);
layer.Open();
layer.Close();
}
finally
{
File.Delete(filePath); // this fails as the file is locked by another process
}
}
  

Any thoughts?

#2

Neil, 
  
 I have recreated your problem, but don’t find solution so far. Just share more information to you, maybe you have some idea to help us solve it.  
  
 The Open method do following thing: 
             rasterImage = new GisImage(); 
             rasterImage.LoadFile(imagePathFilename); 
             worldFile = GetImageWorldFile(); 
  
 The Close method do following thing: 
             rasterImage = null; 
  
 So I think in Close method, it should done more things to dispose object. 
  
 Thanks, 
 James

#3

James,


Thanks for the reply.  I'm guessing the GisImage is one of the internal classes that I can't see nor have access to.


But I guess in general terms it must be holding a handle open on the file until it is garbage collected (or the application terminates if there is no finalizer).  I would be expecting that the close method would call a method on the image (like close or dispose) that would release that handle/close the stream.


I had also added a GC.Collect() previously into the test to see if that would release the file - but it didn't either.  Not that I would want to do this in production code.


I can't really be of much more help - the implication that I'm deriving from this is that I would have to stop the application generating the map tiles if it was using an ECW to update the ECW.  Now maybe this needs to be done for speed and caching considerations?  In this case it would still be nice to have a method that would actually close access to the file.


Neil.



#4

Neil, 
  
 Thanks for your information, I am still looking for solution, and also I sent email to you about detail for GisImage. 
  
 Let me know if you have any new ideas. 
  
 Thanks, 
 James

#5

James,


I've replied to your email with some more information - of where I think the problem actually is.


Neil.



#6

Neil, 
  
 I have tried to implement your code to GisImage, but still has the same problem, it seems the code below couldn’t really dispose the file handler 
             // get and explcitly invoke the finalizer 
             var finalizeMethod = loadedGeoRasterWrapper.GetType().GetMethod(“Finalize”, BindingFlags.Instance | BindingFlags.NonPublic); 
             finalizeMethod.Invoke(loadedGeoRasterWrapper, null); 
  
             GC.SuppressFinalize(loadedGeoRasterWrapper); 
  
 I will keep researching on the solution, any progress I will update to you, thanks for your help. 
  
 James

#7

James, 
  
 I’m a little surprised I had a couple of my colleagues run the same test code on their machines and it works ok.  We are all running x64 machines if that makes any difference. 
  
 Neil.

#8

Neil, 
  
 Maybe my environment has problem, any way I have implemented it to our core, you can get the latest development daily build (5.0.150.0) and have another try. 
  
 Thanks, 
 James  


#9

Thanks James, will try it out when it's available and let you know.



#10

You’re welcome, Neil.