The process cannot access the file (in Windows2003 only)

[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

 

[Mike]

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.

Was it the active process? You must of opened it and forgot to close
it before you began the work process.

Come to think of it, I'm new to .NET myself and I noticed if I work on
files that are across the drive, you will give file errors related to
security. So if the source is on a network drive, that might explain
it. For now, until I get this Manifest, Security baloney understood, I
am just moving my work and test files to local drives.

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

Just trying to instill to trust what the errors say - don't over think
the problem. My favorite technique in both problem solving and
programming is divide and conquer.

That said, we all go through these like this where odd things crop up
and we don't see it when its right there in our face. That is whats
great about the user support forum system - you get mucho 3rd eyes.

--

 

[Mike]

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.

Was it the active process? You must of opened it and forgot to close
it before you began the work process.

Come to think of it, I'm new to .NET myself and I noticed if I work on
files that are across the drive, you will give file errors related to
security. So if the source is on a network drive, that might explain
it. For now, until I get this Manifest, Security baloney understood, I
am just moving my work and test files to local drives.

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

Just trying to instill to trust what the errors say - don't over think
the problem. My favorite technique in both problem solving and
programming is divide and conquer.

That said, we all go through these like this where odd things crop up
and we don't see it when its right there in our face. That is whats
great about the user support forum system - you get mucho 3rd eyes.

--

 

[Anthony Lopez]

The file is on the D-drive on the local-host.

I couldn't agree more - I too am not trying to over think this. That is why
I keep mentioning that this code base works on XP and 2000 server. I copied
the code-base to a Windows2003 server. Should work the same, yes! Well it is
not. My divide was and still is Windows2003 Server versus XP and 2K until
which time someone can explain why it shouldn't be this way.

I hoping to hear that maybe the version of .Net 1.1 framework on 2003 Server
has some minor differences or something like that.

I not only trust the error message, I also trust the code with its flaws in
programming style.

 

[Anthony Lopez]

The file is on the D-drive on the local-host.

I couldn't agree more - I too am not trying to over think this. That is why
I keep mentioning that this code base works on XP and 2000 server. I copied
the code-base to a Windows2003 server. Should work the same, yes! Well it is
not. My divide was and still is Windows2003 Server versus XP and 2K until
which time someone can explain why it shouldn't be this way.

I hoping to hear that maybe the version of .Net 1.1 framework on 2003 Server
has some minor differences or something like that.

I not only trust the error message, I also trust the code with its flaws in
programming style.

 

[Mike]

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
..NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management
across all networks and OS, that to guess this File Sharing Error is
related to .NET versions (again outside of security), it just will
break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed
the file is open. Well, is it suppose to be?

--

The file is on the D-drive on the local-host.

I couldn't agree more - I too am not trying to over think this. That is why
I keep mentioning that this code base works on XP and 2000 server. I copied
the code-base to a Windows2003 server. Should work the same, yes! Well it is
not. My divide was and still is Windows2003 Server versus XP and 2K until
which time someone can explain why it shouldn't be this way.

I hoping to hear that maybe the version of .Net 1.1 framework on 2003 Server
has some minor differences or something like that.

I not only trust the error message, I also trust the code with its flaws in
programming style.

 

[Mike]

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
..NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management
across all networks and OS, that to guess this File Sharing Error is
related to .NET versions (again outside of security), it just will
break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed
the file is open. Well, is it suppose to be?

--

The file is on the D-drive on the local-host.

I couldn't agree more - I too am not trying to over think this. That is why
I keep mentioning that this code base works on XP and 2000 server. I copied
the code-base to a Windows2003 server. Should work the same, yes! Well it is
not. My divide was and still is Windows2003 Server versus XP and 2K until
which time someone can explain why it shouldn't be this way.

I hoping to hear that maybe the version of .Net 1.1 framework on 2003 Server
has some minor differences or something like that.

I not only trust the error message, I also trust the code with its flaws in
programming style.

 

[John]

I was unable to reproduce the problem. I tried on a
2003 SP1 as well as 2003 SP2 server. Do you have
a short bit of code that demonstrates the problem?

Have you tested on multiple 2003 servers?

I created a windows form project with a single button
on the form in VS2003 with the code below. I also
made sure there was a c:\temp folder with a test.txt
file in it along with a c:\temp\temp folder.

Imports System.IO

Public Class Form1
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "
' Omitted
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim FullPathName As String = "c:\temp\test.txt"
Dim NewFullPathName As String = "c:\temp\temp\test.txt"
If File.Exists(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
End Sub

End Class

 

[John]

I was unable to reproduce the problem. I tried on a
2003 SP1 as well as 2003 SP2 server. Do you have
a short bit of code that demonstrates the problem?

Have you tested on multiple 2003 servers?

I created a windows form project with a single button
on the form in VS2003 with the code below. I also
made sure there was a c:\temp folder with a test.txt
file in it along with a c:\temp\temp folder.

Imports System.IO

Public Class Form1
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "
' Omitted
#End Region

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim FullPathName As String = "c:\temp\test.txt"
Dim NewFullPathName As String = "c:\temp\temp\test.txt"
If File.Exists(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
End Sub

End Class

 

[Mike]

Anthony, below is a handy utility I use a lot (ported to VB) to test
file sharing:

--------- Cut Here save in testfileblock.vb ----
' File: TestFileLock.vb

Option Strict on
Option Explicit On

imports system
imports system.console
imports system.io

Module module1

Function log(Fmt As String, ParamArray args() As Object) As Integer
Writeline(fmt,args)
End Function

sub main(ByVal args() As String)
if (args.length = 0 orElse Array.IndexOf(Args,"/?") > -1) then
log("usage: testfilelock filename [access:mode] [share:mode]")
log("")
log("opens existing filename with access and share modes.")
log("")
log("access:mode where mode is:")
log(" r open for reading")
log(" w open for writing")
log(" rw open for reading & writing")
log("")
log("share:mode where mode is:")
log(" r allow others to open for reading")
log(" w allow others to open for writing")
log(" rw allow others to open for reading/writing")
log("")
log("examples:")
log("")
log(" testfilelock c:\test1 access:r share:rw")
log(" testfilelock c:\test1 access:rw")
log("")
exit sub
end if

dim fname as string = args(0)
dim omode as FileMode = FileMode.Open
dim amode as FileAccess = FileAccess.Read
dim smode as FileShare = FileShare.None

for i as integer = 1 to Args.Length-1
dim tmode as string() = args(i).tolower.split(":"c)
if (tmode(0) = "access") then
select case(tmode(1))
case "r" : amode = FileAccess.Read
case "w" : amode = FileAccess.Write
case "rw" : amode = FileAccess.ReadWrite
end select
elseif (tmode(0) = "share") then
select case(tmode(1))
case "r" : smode = FileShare.Read
case "w" : smode = FileShare.Write
case "rw" : smode = FileShare.ReadWrite
end select
end if
next

try
Dim sr As FileStream = File.Open(fname, omode, amode, smode)
log("* File {0} open with access: {1} share: {2}",fname,
amode, smode)
log("- Press ANY KEY to close file")
ReadKey(true)
sr.close()
catch ex as exception
log("! OPEN FILE ERROR: "+ex.Message)
finally
end try
end sub

end Module
--------- Cut Here ----

Usage:

TestFileLock C:\MYFILENAME open:read share:read

The above is the same open/share mode as File.Open(). To repeat the
sharing error, lock it like so:

TestFileLock C:\MYFILENAME open:read

then run your application. It should give you the same error like you
got.

--

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
.NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management across
all networks and OS, that to guess this File Sharing Error is related to
.NET versions (again outside of security), it just will break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed the
file is open. Well, is it suppose to be?

 

[Mike]

Anthony, below is a handy utility I use a lot (ported to VB) to test
file sharing:

--------- Cut Here save in testfileblock.vb ----
' File: TestFileLock.vb

Option Strict on
Option Explicit On

imports system
imports system.console
imports system.io

Module module1

Function log(Fmt As String, ParamArray args() As Object) As Integer
Writeline(fmt,args)
End Function

sub main(ByVal args() As String)
if (args.length = 0 orElse Array.IndexOf(Args,"/?") > -1) then
log("usage: testfilelock filename [access:mode] [share:mode]")
log("")
log("opens existing filename with access and share modes.")
log("")
log("access:mode where mode is:")
log(" r open for reading")
log(" w open for writing")
log(" rw open for reading & writing")
log("")
log("share:mode where mode is:")
log(" r allow others to open for reading")
log(" w allow others to open for writing")
log(" rw allow others to open for reading/writing")
log("")
log("examples:")
log("")
log(" testfilelock c:\test1 access:r share:rw")
log(" testfilelock c:\test1 access:rw")
log("")
exit sub
end if

dim fname as string = args(0)
dim omode as FileMode = FileMode.Open
dim amode as FileAccess = FileAccess.Read
dim smode as FileShare = FileShare.None

for i as integer = 1 to Args.Length-1
dim tmode as string() = args(i).tolower.split(":"c)
if (tmode(0) = "access") then
select case(tmode(1))
case "r" : amode = FileAccess.Read
case "w" : amode = FileAccess.Write
case "rw" : amode = FileAccess.ReadWrite
end select
elseif (tmode(0) = "share") then
select case(tmode(1))
case "r" : smode = FileShare.Read
case "w" : smode = FileShare.Write
case "rw" : smode = FileShare.ReadWrite
end select
end if
next

try
Dim sr As FileStream = File.Open(fname, omode, amode, smode)
log("* File {0} open with access: {1} share: {2}",fname,
amode, smode)
log("- Press ANY KEY to close file")
ReadKey(true)
sr.close()
catch ex as exception
log("! OPEN FILE ERROR: "+ex.Message)
finally
end try
end sub

end Module
--------- Cut Here ----

Usage:

TestFileLock C:\MYFILENAME open:read share:read

The above is the same open/share mode as File.Open(). To repeat the
sharing error, lock it like so:

TestFileLock C:\MYFILENAME open:read

then run your application. It should give you the same error like you
got.

--

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
.NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management across
all networks and OS, that to guess this File Sharing Error is related to
.NET versions (again outside of security), it just will break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed the
file is open. Well, is it suppose to be?

 

[Anthony Lopez]

Mike

Your words of wisdom is seemingly panning out. You know "CLPE" It appears
that the problem stems from anther area of code - unfortunately I am
circling the real issue and can not report on the exact issue just yet.
However I did not want to let too much time pass before I paid my homage to
your wisdom and logic

My only consolation is so far everyone is right in this matter and
everyone's advise proved helpful in getting me closer to this bug. And I can
say with a fair amount of confidence that the original code that I submitted
wasn't flawed and was doing what it should be doing.

If the real problem is relevant to this post, I will follow up with the
actual cause and solution.

Thanks

Anthony, below is a handy utility I use a lot (ported to VB) to test
file sharing:

--------- Cut Here save in testfileblock.vb ----
' File: TestFileLock.vb

Option Strict on
Option Explicit On

imports system
imports system.console
imports system.io

Module module1

Function log(Fmt As String, ParamArray args() As Object) As Integer
Writeline(fmt,args)
End Function

sub main(ByVal args() As String)
if (args.length = 0 orElse Array.IndexOf(Args,"/?") > -1) then
log("usage: testfilelock filename [access:mode] [share:mode]")
log("")
log("opens existing filename with access and share modes.")
log("")
log("access:mode where mode is:")
log(" r open for reading")
log(" w open for writing")
log(" rw open for reading & writing")
log("")
log("share:mode where mode is:")
log(" r allow others to open for reading")
log(" w allow others to open for writing")
log(" rw allow others to open for reading/writing")
log("")
log("examples:")
log("")
log(" testfilelock c:\test1 access:r share:rw")
log(" testfilelock c:\test1 access:rw")
log("")
exit sub
end if

dim fname as string = args(0)
dim omode as FileMode = FileMode.Open
dim amode as FileAccess = FileAccess.Read
dim smode as FileShare = FileShare.None

for i as integer = 1 to Args.Length-1
dim tmode as string() = args(i).tolower.split(":"c)
if (tmode(0) = "access") then
select case(tmode(1))
case "r" : amode = FileAccess.Read
case "w" : amode = FileAccess.Write
case "rw" : amode = FileAccess.ReadWrite
end select
elseif (tmode(0) = "share") then
select case(tmode(1))
case "r" : smode = FileShare.Read
case "w" : smode = FileShare.Write
case "rw" : smode = FileShare.ReadWrite
end select
end if
next

try
Dim sr As FileStream = File.Open(fname, omode, amode, smode)
log("* File {0} open with access: {1} share: {2}",fname,
amode, smode)
log("- Press ANY KEY to close file")
ReadKey(true)
sr.close()
catch ex as exception
log("! OPEN FILE ERROR: "+ex.Message)
finally
end try
end sub

end Module
--------- Cut Here ----

Usage:

TestFileLock C:\MYFILENAME open:read share:read

The above is the same open/share mode as File.Open(). To repeat the
sharing error, lock it like so:

TestFileLock C:\MYFILENAME open:read

then run your application. It should give you the same error like you
got.

--

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
.NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management across
all networks and OS, that to guess this File Sharing Error is related to
.NET versions (again outside of security), it just will break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed the
file is open. Well, is it suppose to be?

 

[Anthony Lopez]

Mike

Your words of wisdom is seemingly panning out. You know "CLPE" It appears
that the problem stems from anther area of code - unfortunately I am
circling the real issue and can not report on the exact issue just yet.
However I did not want to let too much time pass before I paid my homage to
your wisdom and logic

My only consolation is so far everyone is right in this matter and
everyone's advise proved helpful in getting me closer to this bug. And I can
say with a fair amount of confidence that the original code that I submitted
wasn't flawed and was doing what it should be doing.

If the real problem is relevant to this post, I will follow up with the
actual cause and solution.

Thanks

Anthony, below is a handy utility I use a lot (ported to VB) to test
file sharing:

--------- Cut Here save in testfileblock.vb ----
' File: TestFileLock.vb

Option Strict on
Option Explicit On

imports system
imports system.console
imports system.io

Module module1

Function log(Fmt As String, ParamArray args() As Object) As Integer
Writeline(fmt,args)
End Function

sub main(ByVal args() As String)
if (args.length = 0 orElse Array.IndexOf(Args,"/?") > -1) then
log("usage: testfilelock filename [access:mode] [share:mode]")
log("")
log("opens existing filename with access and share modes.")
log("")
log("access:mode where mode is:")
log(" r open for reading")
log(" w open for writing")
log(" rw open for reading & writing")
log("")
log("share:mode where mode is:")
log(" r allow others to open for reading")
log(" w allow others to open for writing")
log(" rw allow others to open for reading/writing")
log("")
log("examples:")
log("")
log(" testfilelock c:\test1 access:r share:rw")
log(" testfilelock c:\test1 access:rw")
log("")
exit sub
end if

dim fname as string = args(0)
dim omode as FileMode = FileMode.Open
dim amode as FileAccess = FileAccess.Read
dim smode as FileShare = FileShare.None

for i as integer = 1 to Args.Length-1
dim tmode as string() = args(i).tolower.split(":"c)
if (tmode(0) = "access") then
select case(tmode(1))
case "r" : amode = FileAccess.Read
case "w" : amode = FileAccess.Write
case "rw" : amode = FileAccess.ReadWrite
end select
elseif (tmode(0) = "share") then
select case(tmode(1))
case "r" : smode = FileShare.Read
case "w" : smode = FileShare.Write
case "rw" : smode = FileShare.ReadWrite
end select
end if
next

try
Dim sr As FileStream = File.Open(fname, omode, amode, smode)
log("* File {0} open with access: {1} share: {2}",fname,
amode, smode)
log("- Press ANY KEY to close file")
ReadKey(true)
sr.close()
catch ex as exception
log("! OPEN FILE ERROR: "+ex.Message)
finally
end try
end sub

end Module
--------- Cut Here ----

Usage:

TestFileLock C:\MYFILENAME open:read share:read

The above is the same open/share mode as File.Open(). To repeat the
sharing error, lock it like so:

TestFileLock C:\MYFILENAME open:read

then run your application. It should give you the same error like you
got.

--

Well, in lieu of some other CPLE (Classic Programmer Logic Error) or
.NET network file security system, I seriously doubt there are
differences in the FILE I/O sharing logic in any OS or .NET framework.

FILE I/O is so COMMON in the interoperability of file management across
all networks and OS, that to guess this File Sharing Error is related to
.NET versions (again outside of security), it just will break many things.

The point is that I can lock a file in any LANGUAGE and .NET
System.IO.FILE class better behave correctly or it will be a show
stopper for many product lines and operations.

So focus on the CPLE <g>

If you can reduce it to:

dim sr as streamreader = nothing
try
sr = File.OpenText("somefile")
catch ex as exception
console.writeline(ex.message)
end try

and repeat the file sharing error over and over again, then you have a
CPLE somewhere. Nothing to do with the OS or framework version. You
would be wasting a lot of time focusing on that.

According to MSDN, OpenText opens the file in

Open Mode = READ
Share Mode = READ

That means at the lowest levels, the win32 function:

handle = CreateFile(filename,
GENERIC_READ
FILE_SHARE_READ,,,)

The only way possible to get a sharing violation error is when another
process or thread in the same process owns an open handle to the file
with the following share modes:

1) SHARE = WRITE but NO SHARE = READ
2) Has SHARE = NOTHING (0)

Those are the rules. It so fundamental to the file I/O sharing in all
DOS, Windows, UNIX, MAC OSes, it ain't funny.

Me thinks you have a different issue. What is the name of the source
file you are trying to open? Didn't you say Process Explorer showed the
file is open. Well, is it suppose to be?