I am building a site where users can upload files, preview them on the website and then (optionally) delete the file again.
I am using ImageGen to render the preview so that we can resize the image as appropriate.
However, when we then go to delete the original image, we get an error stating that the file can't be deleted as it is still in use by another process.
Is it possible that ImageGen isn't releasing the file completely once it's finished resizing it?
It's possible I suppose since ImageGen opens a file to read its contents in order to resize it. It's a read-only lock though and even that should be short-lived. Perhaps .net is being 'helpful' and holding on to it longer than it should. I'll check into it and report back.
As a work-around, we've added a call to the garbage collector inside ImageGen.ashx. This appears to 'fix' the problem, but I wouldn't want to go into production with this!
public void ProcessRequest(System.Web.HttpContext context)
{
ImageGen.ImageGenQueryStringParser parser = new ImageGen.ImageGenQueryStringParser();
parser.Process(context);
parser = null;
System.GC.Collect();
}
I don't know the internals of your code, but we've had similar problems in the past with image resizing and the problem was related to a .NET Graphics object which we hadn't disposed of. We switched to declaring them in a 'using' block and that solved the problem.
Haha, yeah, that would do it! But as you say, forcing the .Collect() isn't a wise practice.
I have using's in most places and dispose of objects and streams immediately. Interestingly, there are only two places the original file is ever considered... an initial FileInfo check and then again if resizing is needed because it isn't already cached. You'd think that would be easy to isolate, wouldn't you? But while I was able to reproduce the problem immediately after firing up the debugger... no problem. This may take more time than I thought. I'll keep you posted of progress.
Can I ask if, when you have the problem deleting files, if you've ever made a request from ImageGen that had only the ?image= parameter and thus ImageGen had only to send the original image? I find a problem in that case but not if there are other params that would do some actual resizing? (I want to be sure I'm chasing the same problem you're experiencing)
I think I have it fixed. Can you let me know your email (or contact me through my website at http://www.percipientstudios.com/about/contact.aspx) and I'll email you an update to confirm if I've found the issue.
Apologies for not getting back to you sooner on this - unfortunately I was ill for a brief period and I've been trying to get back on top of things ever since!
I see from the changelog that you have this fix in v2.9 - we'll upgrade and take a look.
Locked Files
Hi,
I am building a site where users can upload files, preview them on the website and then (optionally) delete the file again.
I am using ImageGen to render the preview so that we can resize the image as appropriate.
However, when we then go to delete the original image, we get an error stating that the file can't be deleted as it is still in use by another process.
Is it possible that ImageGen isn't releasing the file completely once it's finished resizing it?
Thanks,
- Chirs
Hi, Chris,
It's possible I suppose since ImageGen opens a file to read its contents in order to resize it. It's a read-only lock though and even that should be short-lived. Perhaps .net is being 'helpful' and holding on to it longer than it should. I'll check into it and report back.
cheers,
doug.
Hi Doug,
As a work-around, we've added a call to the garbage collector inside ImageGen.ashx. This appears to 'fix' the problem, but I wouldn't want to go into production with this!
I don't know the internals of your code, but we've had similar problems in the past with image resizing and the problem was related to a .NET Graphics object which we hadn't disposed of. We switched to declaring them in a 'using' block and that solved the problem.
Hope this helps!?
Hi, Chris,
Haha, yeah, that would do it! But as you say, forcing the .Collect() isn't a wise practice.
I have using's in most places and dispose of objects and streams immediately. Interestingly, there are only two places the original file is ever considered... an initial FileInfo check and then again if resizing is needed because it isn't already cached. You'd think that would be easy to isolate, wouldn't you? But while I was able to reproduce the problem immediately after firing up the debugger... no problem. This may take more time than I thought. I'll keep you posted of progress.
cheers,
doug.
Hi Doug,
Thanks for the quick response - much appreciated.
Is ImageGen open source? We'd be happy to take a look if you'd like a hand?
Thanks,
- Chris
Hi, Chris,
Sorry, not open source, but thanks for the offer!
Can I ask if, when you have the problem deleting files, if you've ever made a request from ImageGen that had only the ?image= parameter and thus ImageGen had only to send the original image? I find a problem in that case but not if there are other params that would do some actual resizing? (I want to be sure I'm chasing the same problem you're experiencing)
Thanks!
doug.
Hello,
I believe the only parameter we were setting was the width.
Thanks,
- Chris
Well, there goes that idea. I'll keep working on it.
Hi, Chris,
Do you see this problem with .PNG files as well as .JPG files? Can you run a quick test for me to confirm my suspicions?
thanks!
doug.
Hi Doug,
We've only tried it with JPGs so far - we'll try with a PNG and let you know...
Thanks,
- Chris
Hi, Chris,
I think I have it fixed. Can you let me know your email (or contact me through my website at http://www.percipientstudios.com/about/contact.aspx) and I'll email you an update to confirm if I've found the issue.
cheers,
doug.
Hi Doug,
Apologies for not getting back to you sooner on this - unfortunately I was ill for a brief period and I've been trying to get back on top of things ever since!
I see from the changelog that you have this fix in v2.9 - we'll upgrade and take a look.
Thanks again for all your help with this!
- Chris
is working on a reply...