Image.FromFile - Locks File

  • Thread starter Thread starter Jeff Gaines
  • Start date Start date
J

Jeff Gaines

I have written a file manage in C Sharp / .NET Framework 2.

I want to show thumbnails for image files and use the following to get an
Image I can use as a thumbnail:

public void SetThumbnail(FileInfo fInfo)
{
string imageFilter = "*.jpg;*.png;*.gif;*.bmp;*.ico";
Image imgTemp;
// Only try for image for image files
if (imageFilter.Contains(fInfo.Extension.ToLower()))
{
try
{
// Image.FromFile locks the image until it is disposed so would prevent
moving/deleting the file
imgTemp = Image.FromFile(fInfo.FullName);
this.ThumbImage = (Image)imgTemp.Clone();
imgTemp.Dispose();
}
catch
{
}
}
else
{
try
{
imgTemp = JLibrary.ImageFromPath(fInfo.FullName);
this.ThumbImage = (Image)imgTemp.Clone();
imgTemp.Dispose();
}
catch
{
}
}
}
}

However, when I try to move/delete an image file with an extension
contained in imageFilter I get an error message that the file is open in
vshost.exe. When I don't call SetThumbnail then I can move/delete image
files at will.
The images concerned come from Image.FromFile, i.e. they are contained in
imageFilter and I had hoped by cloning the image and then disposing the
original I could overcome this issue. However, that is not the case.
The good news is I have had the problem for a year or so and have managed
to pin down where it arises - the bad news is I don't know how to overcome
the problem.

Any suggestions please, I have done what I thought I needed to do but it's
not working as I expected.
 
Rather than cloning create a *new* bitmap from this one and it should
work... (I remember to have seen this kind workaround).

It reminds me I always wanted to know why FromFile have this behavior
(perhaps at a low level Windows differs reading the bitmap and will really
read bits when a graphical operation is realy performed ??)
 
Rather than cloning create a new bitmap from this one and it should
work... (I remember to have seen this kind workaround).
Click to expand...

Thank you very much Patrice, that does it :-)
It reminds me I always wanted to know why FromFile have this behavior
(perhaps at a low level Windows differs reading the bitmap and will really
read bits when a graphical operation is realy performed ??)
Click to expand...

Don't know - but it is a nuisance and I would have thought Clone should
work.
 
IMO clone just repro the underlying implementation (basically the DNA ;-))
so your clone has the same problem.

Actually I asked the "why" in a win32 group and I'll try to give the
feedback I've got here..

For now I would say that what happens is that Windows keeps a system memory
copy of each bitmap (perhaps to handle display mode changes ?) but if the
file is loaded from a file, you can save the system memory used by this copy
by locking the file and reloading the bitmap data as needed...

When you create a new bitmap rather than cloning, Windows has no other issue
than to revert back to keeping a system memory copy...
 
Patrice said:
IMO clone just repro the underlying implementation (basically the DNA ;-))
so your clone has the same problem.

Actually I asked the "why" in a win32 group and I'll try to give the
feedback I've got here..
Click to expand...

A quick check reveals that GDI+ is not doing delayed reading of the
file, and that it's the native GDI+ keeping the file handle open.

I can only guess it does this for the SaveAdd() functions (and perhaps
others) that operate on the file after the Image object is created.
 
To add to the thread, I often load the image to a MemoryStream and use
Image.FromStream instead. This way the file is released when all the bytes
are loaded.

MemoryStream ms = new MemoryStream(File.ReadAllBytes(imgPath));
Image img = Image.FromStream(ms);

The file is released, but the MemoryStream object will be referenced by the
image and kept alive for the lifespan of the image.
 
Back
Top