The process cannot access the file (in Windows2003 only)

[Anthony Lopez]

I have an application that is working in WindowsXP and Windows2000 server. I
recently moved it onto a new Windows2003 Server Service Pack 2 machine. It
is now getting an error message which reads "The process cannot access the
file <filename> because it is being used by another process"

this is what I have (abreviated version):

If File.Exist(FullPathName) Then
Dim sr As StreamReader = File.OpenText(FullPathName)
Dim sw As StreamWriter = File.CreateText(NewFullPathName)

... do some work

sw.Flush()
sw.Close()
sr.Close()

File.Delete(FullPathName)
File.Move(NewFullPathName, FullPathName)
End If


I want to be brief, but I have posted this to two other .Net Newsgroups and
they keep attempting to answer the wrong question. So in an effort to short
cut this I am using .Net 1.1 and the help indicates that close() method for
StreamReader/StreamWriter calls .dispose(True)

And that since I am using VB I can not use the "using" C# keyword.

Again what I am looking for is the difference between XP/2K versus 2003
Server and how I can fix this.

 

[Mike]

Anthony,

where are you getting the file sharing violation? Try this:

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

 

[Mike]

Anthony,

where are you getting the file sharing violation? Try this:

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

 

[Anthony Lopez]

OK, I made the suggested changes to the code as specified below, and it it
in fact issuing the "! Open for reading error: The process cannot access the
file <filename> because it is being used by another process"

Now please recall, this is its initial and only attempt to open this file.
No other process should be opening it before this point and why does it work
in XP and 2000 server??? Hmmmmm

 

[Anthony Lopez]

OK, I made the suggested changes to the code as specified below, and it it
in fact issuing the "! Open for reading error: The process cannot access the
file <filename> because it is being used by another process"

Now please recall, this is its initial and only attempt to open this file.
No other process should be opening it before this point and why does it work
in XP and 2000 server??? Hmmmmm

 

[Family Tree Mike]

I have an application that is working in WindowsXP and Windows2000 server.
I
recently moved it onto a new Windows2003 Server Service Pack 2 machine. It
is now getting an error message which reads "The process cannot access the
file <filename> because it is being used by another process"

this is what I have (abreviated version):

If File.Exist(FullPathName) Then
Dim sr As StreamReader = File.OpenText(FullPathName)
Dim sw As StreamWriter = File.CreateText(NewFullPathName)

... do some work

sw.Flush()
sw.Close()
sr.Close()

File.Delete(FullPathName)
File.Move(NewFullPathName, FullPathName)
End If


I want to be brief, but I have posted this to two other .Net Newsgroups
and
they keep attempting to answer the wrong question. So in an effort to
short
cut this I am using .Net 1.1 and the help indicates that close() method
for
StreamReader/StreamWriter calls .dispose(True)

And that since I am using VB I can not use the "using" C# keyword.

Again what I am looking for is the difference between XP/2K versus 2003
Server and how I can fix this.

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may not
complete the operation between the code lines. Try a sleep of 100 ms.

 

[Family Tree Mike]

I have an application that is working in WindowsXP and Windows2000 server.
I
recently moved it onto a new Windows2003 Server Service Pack 2 machine. It
is now getting an error message which reads "The process cannot access the
file <filename> because it is being used by another process"

this is what I have (abreviated version):

If File.Exist(FullPathName) Then
Dim sr As StreamReader = File.OpenText(FullPathName)
Dim sw As StreamWriter = File.CreateText(NewFullPathName)

... do some work

sw.Flush()
sw.Close()
sr.Close()

File.Delete(FullPathName)
File.Move(NewFullPathName, FullPathName)
End If


I want to be brief, but I have posted this to two other .Net Newsgroups
and
they keep attempting to answer the wrong question. So in an effort to
short
cut this I am using .Net 1.1 and the help indicates that close() method
for
StreamReader/StreamWriter calls .dispose(True)

And that since I am using VB I can not use the "using" C# keyword.

Again what I am looking for is the difference between XP/2K versus 2003
Server and how I can fix this.

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may not
complete the operation between the code lines. Try a sleep of 100 ms.

 

[Family Tree Mike]

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may not
complete the operation between the code lines. Try a sleep of 100 ms.

And, now I see that Peter Duniho gave you these same answers in
..DotNet.Framework...

 

[Family Tree Mike]

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may not
complete the operation between the code lines. Try a sleep of 100 ms.

And, now I see that Peter Duniho gave you these same answers in
..DotNet.Framework...

 

[Mike]

Well, there are no gremlins or carbon-based random growth patterns.
The system is given you a file lock or sharing error on the file
being opened.

Now I would get the error number because it can be 5 (exclusive lock)
or 32 (sharing lock). If you don't expect it or don't care to be
open, then you might want to open it in

GENERIC_READ,
FILE_SHARE_READ

mode. But unless who ever has it open has FILE_SHARE_READ as well,
then you get these sort of errors.

I believe File.OpenFile() opens it for READING as it is documented,
that means that the other process must have FILE_SHARE_READ to allow
you to open it. You have no control over that.

But if this a design issue and that file is open somewhere unexpected,
and you don't know how, then you have to dig into how that is
happening. This is where excellent tools from SysInternals.com:

PROCEXP.EXE (Process Explorer)
Handles.exe
FileMon

Will help list the processes and the files that they have open. These
utilities can be downloaded from sysinternals.com by Mark Russinovich
who is now works for MS and the website is now owned by MS.

This page has the utilities.

http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx

PS:, I was speaking C/C++ mode with the CreateFile() file attributes.
Lets see the equivalent for IO.FILE, ok here:

http://msdn.microsoft.com/en-us/library/4z36sx0f.aspx

Yeah,, you can use

FileStream(name, FileMode.Open, FileAccess.Read, FileShare.Read)

to be more explicit to make sure you open it in the write mode.

But if you don't expect this, then you need the tools to see who owns
them.

Some other things to check:

- Seen if you have a hanging process still in memory with task
manager. If you see it, kill it. This is not uncommon to happen
during development.

- Try rebooting.

--

 

[Mike]

Well, there are no gremlins or carbon-based random growth patterns.
The system is given you a file lock or sharing error on the file
being opened.

Now I would get the error number because it can be 5 (exclusive lock)
or 32 (sharing lock). If you don't expect it or don't care to be
open, then you might want to open it in

GENERIC_READ,
FILE_SHARE_READ

mode. But unless who ever has it open has FILE_SHARE_READ as well,
then you get these sort of errors.

I believe File.OpenFile() opens it for READING as it is documented,
that means that the other process must have FILE_SHARE_READ to allow
you to open it. You have no control over that.

But if this a design issue and that file is open somewhere unexpected,
and you don't know how, then you have to dig into how that is
happening. This is where excellent tools from SysInternals.com:

PROCEXP.EXE (Process Explorer)
Handles.exe
FileMon

Will help list the processes and the files that they have open. These
utilities can be downloaded from sysinternals.com by Mark Russinovich
who is now works for MS and the website is now owned by MS.

This page has the utilities.

http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx

PS:, I was speaking C/C++ mode with the CreateFile() file attributes.
Lets see the equivalent for IO.FILE, ok here:

http://msdn.microsoft.com/en-us/library/4z36sx0f.aspx

Yeah,, you can use

FileStream(name, FileMode.Open, FileAccess.Read, FileShare.Read)

to be more explicit to make sure you open it in the write mode.

But if you don't expect this, then you need the tools to see who owns
them.

Some other things to check:

- Seen if you have a hanging process still in memory with task
manager. If you see it, kill it. This is not uncommon to happen
during development.

- Try rebooting.

--

 

[Anthony Lopez]

The below was my reply to Peter Duniho. In light of this information do we
still think that the delete is the issue? The way I am reading the code we
are bombing at the first attempt to open the file, and we aren't getting
past that point. Should I still put in a delay.



The code has been modified as follows based on the advisement of another
posting.

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

The message box displayed was indeed the


"! OPEN FOR READING ERROR: The process cannot access the file <filename>
because it is being used by another process"

As can be seen, we did not make it to the point were we would attempt to
delete and/or move the file. For that matter we did not even make it to the
next step were we create a new text file.

As for the using issue, I have .Net 1.1 and it looks like "using" was added
in 2.0 oh well would have been nice.

 

[Anthony Lopez]

The below was my reply to Peter Duniho. In light of this information do we
still think that the delete is the issue? The way I am reading the code we
are bombing at the first attempt to open the file, and we aren't getting
past that point. Should I still put in a delay.



The code has been modified as follows based on the advisement of another
posting.

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

The message box displayed was indeed the


"! OPEN FOR READING ERROR: The process cannot access the file <filename>
because it is being used by another process"

As can be seen, we did not make it to the point were we would attempt to
delete and/or move the file. For that matter we did not even make it to the
next step were we create a new text file.

As for the using issue, I have .Net 1.1 and it looks like "using" was added
in 2.0 oh well would have been nice.

 

[Mike]

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may
not complete the operation between the code lines. Try a sleep of 100 ms.

Cardinal rule of thumb in Sync 101 - never user time to synchronize
objects - it will inevitable and intermittently fail or if you need to
use it, it means something else is wrong.

File.Delete is a synchronous call. It calls the Win32 DeleteFile()
function. It must never return until it is finish. If it does, it
generally means:

- OS File System Database Corruption
(i.e, NTFS b-trees index files)
- OS Kernel Driver Problem

In other words, something is messed up.

--

 

[Mike]

Two things.
First, the "Using" keyword is also valid in vb.net.
Second, try a delay between the file.delete and file.move. The os may
not complete the operation between the code lines. Try a sleep of 100 ms.

Cardinal rule of thumb in Sync 101 - never user time to synchronize
objects - it will inevitable and intermittently fail or if you need to
use it, it means something else is wrong.

File.Delete is a synchronous call. It calls the Win32 DeleteFile()
function. It must never return until it is finish. If it does, it
generally means:

- OS File System Database Corruption
(i.e, NTFS b-trees index files)
- OS Kernel Driver Problem

In other words, something is messed up.

--

 

[Family Tree Mike]

The below was my reply to Peter Duniho. In light of this information do we
still think that the delete is the issue? The way I am reading the code we
are bombing at the first attempt to open the file, and we aren't getting
past that point. Should I still put in a delay.



The code has been modified as follows based on the advisement of another
posting.

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

The message box displayed was indeed the


"! OPEN FOR READING ERROR: The process cannot access the file <filename>
because it is being used by another process"

As can be seen, we did not make it to the point were we would attempt to
delete and/or move the file. For that matter we did not even make it to
the
next step were we create a new text file.

As for the using issue, I have .Net 1.1 and it looks like "using" was
added
in 2.0 oh well would have been nice.

I think "the other" Mike is on the right track with Rebooting then
FileMon.

 

[Family Tree Mike]

The below was my reply to Peter Duniho. In light of this information do we
still think that the delete is the issue? The way I am reading the code we
are bombing at the first attempt to open the file, and we aren't getting
past that point. Should I still put in a delay.



The code has been modified as follows based on the advisement of another
posting.

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

The message box displayed was indeed the


"! OPEN FOR READING ERROR: The process cannot access the file <filename>
because it is being used by another process"

As can be seen, we did not make it to the point were we would attempt to
delete and/or move the file. For that matter we did not even make it to
the
next step were we create a new text file.

As for the using issue, I have .Net 1.1 and it looks like "using" was
added
in 2.0 oh well would have been nice.

I think "the other" Mike is on the right track with Rebooting then
FileMon.

 

[Anthony Lopez]

Thanks good suggestions, I did use process explorer and only saw one process
with the file opened and that was my process. Not being a ace process
explorer user I may not have used the tool to its fullest.

I will take a look at filemon

Thanks

P.S. I wonder if Darwin would agree with that no carbon-based random growth
patterns statement .. Ha ha

 

[Anthony Lopez]

Thanks good suggestions, I did use process explorer and only saw one process
with the file opened and that was my process. Not being a ace process
explorer user I may not have used the tool to its fullest.

I will take a look at filemon

Thanks

P.S. I wonder if Darwin would agree with that no carbon-based random growth
patterns statement .. Ha ha

 

[Mike]

The below was my reply to Peter Duniho. In light of this information do we
still think that the delete is the issue? The way I am reading the code we
are bombing at the first attempt to open the file, and we aren't getting
past that point. Should I still put in a delay.

The code has been modified as follows based on the advisement of another
posting.

If File.Exist(FullPathName) Then

Dim sr As StreamReader
Dim sw As StreamWriter
try
sr = File.OpenText(FullPathName)
try
sw = File.CreateText(NewFullPathName)

... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
finally
sw.close()
end try
catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
finally
sr.Close()
end try

try
File.Delete(FullPathName)
try
File.Move(NewFullPathName, FullPathName)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
end try

End If

The message box displayed was indeed the


"! OPEN FOR READING ERROR: The process cannot access the file <filename>
because it is being used by another process"

As can be seen, we did not make it to the point were we would attempt to
delete and/or move the file. For that matter we did not even make it to the
next step were we create a new text file.

Thats correct. Now, technically, you would put an RETURN FALSE in the
catch so that it doesn't go to the next block outside the catch block.

You should make a function out of this like so:

Function WorkOnFile(src as string, tar as string) as BOOLEAN

If not File.Exists(src) Then
return FALSE
end if

Dim sr As StreamReader
Dim sw As StreamWriter
try

sr = File.OpenText(src)
try
sw = File.CreateText(tar)

'... do your work ..

catch ex as exception
msgbox("! OPEN FOR WRITING ERROR : "+ex.Message)
return FALSE
finally
sw.close()
end try

catch ex as exception
msgbox("! OPEN FOR READING ERROR: "+ex.Message)
return FALSE
finally
sr.Close()
end try

try
File.Delete(src)
try
File.Move(tar, src)
catch ex as exception
msgbox("! ERROR MOVING FILE: "+ex.Message)
return FALSE
end try
catch ex as exception
msgbox("! ERROR DELETING FILE: "+ex.Message)
return FALSE
end try

return TRUE

End Function