Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Image.FromFile - Locks File

36 views
Skip to first unread message

Jeff Gaines

unread,
Sep 17, 2009, 6:51:22 AM9/17/09
to
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.

--
Jeff Gaines Dorset UK
This is as bad as it can get, but don't bet on it

Patrice

unread,
Sep 17, 2009, 7:01:28 AM9/17/09
to
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 ??)

--
Patrice


"Jeff Gaines" <jgaines...@yahoo.co.uk> a �crit dans le message de groupe
de discussion : xn0gf9e1s...@msnews.microsoft.com...

Jeff Gaines

unread,
Sep 17, 2009, 8:08:55 AM9/17/09
to
On 17/09/2009 in message <eBdU2Y4...@TK2MSFTNGP02.phx.gbl> Patrice
wrote:

>Rather than cloning create a new bitmap from this one and it should

>work... (I remember to have seen this kind workaround).

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 ??)

Don't know - but it is a nuisance and I would have thought Clone should
work.

--
Jeff Gaines Dorset UK

There is no reason anyone would want a computer in their home.
(Ken Olson, president Digital Equipment, 1977)

Patrice

unread,
Sep 17, 2009, 10:32:24 AM9/17/09
to
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

"Jeff Gaines" <jgaines...@yahoo.co.uk> a �crit dans le message de groupe

de discussion : xn0gf9g5s...@msnews.microsoft.com...

Scott Seligman

unread,
Sep 17, 2009, 12:52:56 PM9/17/09
to
"Patrice" <http://scribe-en.blogspot.com/> wrote:
>
>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..

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.

--
--------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
The avalanche has already started. It is too late for the pebbles to
vote. -- Ambassador Kosh Naranek in Babylon 5:"Believers"

Morten Wennevik [C# MVP]

unread,
Sep 18, 2009, 4:01:02 AM9/18/09
to
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.

--
Happy Coding!
Morten Wennevik [C# MVP]

0 new messages