IIS is keeping hold of my generated files

Question

My web application generates pdf files and either e-mails or faxes them to our customers. Somehow IIS6 is keeping hold of the file and blocking any other requests for it claiming the old '..the process cannot access the file 'xxx.pdf' because it is being used by another process.'

When I recycle the application pool all is ok. Does anybody know why this is happening and how can I stop it.

Thanks

Answer 1

I'd look through your code and make sure all handles to open (generated) files have been closed properly. Sometimes you just can't rely on the garbage collector to sort these things out.

Answer 2

We had a similar problem once with some images that users were modifying and it was that we hadn't properly disposed of the image.

Answer 3

Sounds like, the files - after being created - are still locked by the worker process. Make sure that you close all the connections for your file. (remember, using using blocks'll take care of that)

Answer 4

Check that all the code writing files on disk properly close every handle using the proper .Close() in the finally clause or trough the "using" clause of C#

byte[] asciiBytes = getPdf(...);
try{
BinaryWriter bw = new BinaryWriter(File.Create(filename));
bw.Write(pdfBytes);
}
finally {
if(null != bw)
bw.Close();
}


Use the Response and the Content-Disposition clause to send the file

Response.ContentType = "application/pdf";
Response.AppendHeader("Content-disposition", "attachment; filename=" + PDID + ".pdf");
Response.WriteFile(filename);
Response.Flush();

The code shown creates and send Pdf files to customer from about 18 months and we've never seen a file locked.

Answer 5

1. Like mentioned before: Take care that you close all open handlers.

2. Sometimes the indexing service of Microsoft blocks files. Exclude your directory

Answer 6

As with everyone said, do call the Close and Dispose method on any IO objects you have open when reading/writing the PDF files.

But I suppose you'd incorporated a 3rd party component? to do the PDF writing for you? If that's the case you might want to check with the vendor and/or its documentation to make sure that you are doing things in the way the vendors intended them to be. Don't trust the black box you got from someone else unless it has proven itself.

Another place to look might be what happens during multiple web request to the PDF files, are you sure that the file is not written simultaneously from multiple places? e.g. 2-3 requests genrating PDF simultaneously? or 2-3 pages along the PDF generation process?

And lastly, you might want to check the exception logs to make sure that nothing is crashing/thread exiting and leaving the file handle open without you noticing it. It happens a lot in multiple threading scenarios, sometimes the thread just crashes and exits - which could happen especially if you use 3rd party components, they might be performing some magic tricks, you'd never know.

Answer 7

This is fixed now, thanks everyone. I was calling .close, but missed a .dispose on one of my streamwriters.