w3wp.exe process locks files for a few seconds

[utagger]

Hi All,

We have a gallery component that allows us to upload images.
An Edit Image Entry user control allows the user to update an image, by
replacing the current one.

Oddly, after replacing an image, if the user tries to replace again
within a few seconds - he gets the following error message:

The process cannot access the file "...X.gif" because it is being used
by another process.

If we wait for over 20 seconds or so, this doesn't happen.

Also, once we get this error, the file then stays locked untill the
w3wp.exe process is killed (or debugging is stopped).

Help!

Thanks,
Uri
CodeOasis.com

[John Timney \(ASP.NET MVP\)]

Sounds like the upload completes and passes the file write off to the file
system, which has not yet completed actually repacing the file - even though
the instruction to start has has completed. I dont think there would be
anyhting you can do about it other than make some informative error
handling. You might try checking that the file can be opened exclusively
before you try and overwrite it or seeing if you can stall the asp page
concluding by getting areturn value from the file write.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

<ut*****@gmail. com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Hi All,

We have a gallery component that allows us to upload images.
An Edit Image Entry user control allows the user to update an image, by
replacing the current one.

Oddly, after replacing an image, if the user tries to replace again
within a few seconds - he gets the following error message:

The process cannot access the file "...X.gif" because it is being used
by another process.

If we wait for over 20 seconds or so, this doesn't happen.

Also, once we get this error, the file then stays locked untill the
w3wp.exe process is killed (or debugging is stopped).

Help!

Thanks,
Uri
CodeOasis.com

[utagger]

Hi John,

In the two methods that I've tried using to write the file, there is no
return value that I can wait for. The methods were:
1) HtmlInputFile's .PostedFile.Sav eAs(...)
2) Creating a FileStream object and using its write method. In this
case, I did wait for the InputStream to finish reading (uploading) the
file and give me a return value.
Both solutions did not help...
I am also disposing of all related objects, BTW.

I find it very strange that the file system would keep a lock on a file
for so long after all handles have been detroyed.
Naturally, I am taking care of showing a more subtle error message to
the user. Moreover, this scenario is not expected to happen often.

However, I would like to get to the bottom of this - to know what's the
cause. I hate 'turning a blind eye' to this sort of thing, as it tends
to come back and 'bite you in the ass'...

Thanks!

[Brad Roberts]

Just shooting in the dark...
If it is a timing issue, maybe the same code that saves the file to disk
could also immediately try to access the file after the write. (This could be
something as simple as querying the FileSystemInfo. ) Doing this in the same
code may give the system enough time to complete anything that is causing it
to hang.

Are there a lot of files in the directory? A large directory could put a
greater burden on the file system. This could be requiring more time to
complete background operations.

"ut*****@gmail. com" wrote:

Hi John,

In the two methods that I've tried using to write the file, there is no
return value that I can wait for. The methods were:
1) HtmlInputFile's .PostedFile.Sav eAs(...)
2) Creating a FileStream object and using its write method. In this
case, I did wait for the InputStream to finish reading (uploading) the
file and give me a return value.
Both solutions did not help...
I am also disposing of all related objects, BTW.

I find it very strange that the file system would keep a lock on a file
for so long after all handles have been detroyed.
Naturally, I am taking care of showing a more subtle error message to
the user. Moreover, this scenario is not expected to happen often.

However, I would like to get to the bottom of this - to know what's the
cause. I hate 'turning a blind eye' to this sort of thing, as it tends
to come back and 'bite you in the ass'...

Thanks!

[Patrice]

Is the file accessed through HTTP before or after being uploaded ? AFAIK
when you access a file through HTTP, IIS lock the file for a "short" period
(I would say 60 s by default ?).

If you are in this case, you could likely stream the file to the browser to
avoid HTTP access...

Patrice


--

<ut*****@gmail. com> a écrit dans le message de
news:11******** **************@ o13g2000cwo.goo glegroups.com.. .

Hi John,

In the two methods that I've tried using to write the file, there is no
return value that I can wait for. The methods were:
1) HtmlInputFile's .PostedFile.Sav eAs(...)
2) Creating a FileStream object and using its write method. In this
case, I did wait for the InputStream to finish reading (uploading) the
file and give me a return value.
Both solutions did not help...
I am also disposing of all related objects, BTW.

I find it very strange that the file system would keep a lock on a file
for so long after all handles have been detroyed.
Naturally, I am taking care of showing a more subtle error message to
the user. Moreover, this scenario is not expected to happen often.

However, I would like to get to the bottom of this - to know what's the
cause. I hate 'turning a blind eye' to this sort of thing, as it tends
to come back and 'bite you in the ass'...

Thanks!

[utagger]

Thanks Brad,

I have tried your approach and unfortunately it produced no effect.
To your question: there are very few files in the directory at this
point (less than 10) - so I doubt that this could be a factor.
Also - what background operations could there be? We're waiting for
everything to complete, and then destroying the handles...

Uri.

[tagger]

Hi Patrice,

I'm affraid I don't know what you mean by 'streaming' the file to the
browser. I'm using regular access as an <img> tag. The upload takes
place using an HtmlInputFile control, which I assume uses HTTP to
transfer the file.

I've researched a little about this (shocking) lock that IIS places on
files. I've even used a registry setting to try to disable it, but that
didn't work.
To disable the caching, I've used the steps described for IIS4 in:
http://support.microsoft.com/default...EN-US;q191742& -
namely: enter a DWORD value in
HKEY_LOCAL_MACH INE\SYSTEM\Curr entControlSet\S ervices\InetInf o\Parameters
called DisableMemoryCa che with a value of 1.
I don't know if this didn't help because I'm using IIS 6, or because my
problem is not related to this locking (although it sounds quite
right).

Thanks,
Uri.

[Patrice]

I meant calling an ASPX page that uses "Response.Write File" to output the
file to the browser. This way the file is not served directly by IIS.

For the upload you upload the *content* of the file using HTTP but this is
your code that creates the final file, not IIS...

Another culprit could be index server or an antivirus software maybe ? You
may want to try the filemon utility (from http://www.sysinternals.com/). It
should hopefully allow to find out what exactly locks this file before
trying a solution...

Good luck.

Patrice

--

"tagger" <ut*****@gmail. com> a écrit dans le message de
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Hi Patrice,

I'm affraid I don't know what you mean by 'streaming' the file to the
browser. I'm using regular access as an <img> tag. The upload takes
place using an HtmlInputFile control, which I assume uses HTTP to
transfer the file.

I've researched a little about this (shocking) lock that IIS places on
files. I've even used a registry setting to try to disable it, but that
didn't work.
To disable the caching, I've used the steps described for IIS4 in:
http://support.microsoft.com/default...EN-US;q191742& -
namely: enter a DWORD value in
HKEY_LOCAL_MACH INE\SYSTEM\Curr entControlSet\S ervices\InetInf o\Parameters
called DisableMemoryCa che with a value of 1.
I don't know if this didn't help because I'm using IIS 6, or because my
problem is not related to this locking (although it sounds quite
right).

Thanks,
Uri.

[tagger]

Hi All,

Well, Patrice's last advice finally nailed it!

I used one of the excellent tools on sysinternals.co m (procexp.exe)
while tracing through the code, and found the culprit: ME!

At some point in the program, I had opened a Bitmap object just to get
the height and width of the image, and forgot to dispose of this
object. This had kept an open handle on the file, and wouldn't let me
try to overwrite it...

Thanks to everyone for your help, and thanks to Patrice for providing
the eventual remedy.

Uri.