> 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.
>

> 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 wrote:
>> 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.
>>

> 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
>
>
> On 5/18/09 4:43 PM, in article ##Fk8JB2JHA.***@TK2MSFTNGP06.phx.gbl, "Mike"
> <unkn***@unknown.tv> wrote:
>
>> 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 wrote:
>>> 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.
>>>
>

> 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 wrote:
>> 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
>>
>>
>> On 5/18/09 4:43 PM, in article ##Fk8JB2JHA.***@TK2MSFTNGP06.phx.gbl, "Mike"
>> <unkn***@unknown.tv> wrote:
>>
>>> 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 wrote:
>>>> 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.
>>>>
>>

> Anthony Lopez wrote:
>> 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. :-)
>
> --
>
>

> 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.
>
>
> On 5/18/09 7:47 PM, in article uB6H4wC2JHA.1***@TK2MSFTNGP03.phx.gbl, "Mike"
> <unkn***@unknown.tv> wrote:
>
>> Anthony Lopez wrote:
>>> 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. :-)
>>
>> --
>>
>>
>

> 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 wrote:
>> 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.
>>
>>
>> On 5/18/09 7:47 PM, in article uB6H4wC2JHA.1***@TK2MSFTNGP03.phx.gbl,
>> "Mike"
>> <unkn***@unknown.tv> wrote:
>>
>>> Anthony Lopez wrote:
>>>> 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, 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.
>
> --
>
>
>
> Mike wrote:
>> 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 wrote:
>>> 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.
>>>
>>>
>>> On 5/18/09 7:47 PM, in article uB6H4wC2JHA.1***@TK2MSFTNGP03.phx.gbl,
>>> "Mike"
>>> <unkn***@unknown.tv> wrote:
>>>
>>>> Anthony Lopez wrote:
>>>>> 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" <arlo***@charter.net> wrote in message
news:C6373C05.2AE9%arlopez@charter.net...
>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.
>

"Family Tree Mike" <FamilyTreeM***@ThisOldHouse.com> wrote in message
news:249CB224-7886-44CB-A3D1-E4378014F49E@microsoft.com...
> "Anthony Lopez" <arlo***@charter.net> wrote in message
> news:C6373C05.2AE9%arlopez@charter.net...
>>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.
> --
> Mike

> "Family Tree Mike" <FamilyTreeM***@ThisOldHouse.com> wrote in message
> news:249CB224-7886-44CB-A3D1-E4378014F49E@microsoft.com...
>> "Anthony Lopez" <arlo***@charter.net> wrote in message
>> news:C6373C05.2AE9%arlopez@charter.net...
>>> 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.
>> --
>> Mike
>
>
> And, now I see that Peter Duniho gave you these same answers in
> .DotNet.Framework...
>

"Anthony Lopez" <arlo***@charter.net> wrote in message
news:C6375DC5.2B00%arlopez@charter.net...
>
> 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.
>
>
>
>
> On 5/18/09 6:19 PM, in article
> 93E91412-DA49-4B5C-85E9-708987CD6***@microsoft.com, "Family Tree Mike"
> <FamilyTreeM***@ThisOldHouse.com> wrote:
>
>> "Family Tree Mike" <FamilyTreeM***@ThisOldHouse.com> wrote in message
>> news:249CB224-7886-44CB-A3D1-E4378014F49E@microsoft.com...
>>> "Anthony Lopez" <arlo***@charter.net> wrote in message
>>> news:C6373C05.2AE9%arlopez@charter.net...
>>>> 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.
>>> --
>>> Mike
>>
>>
>> And, now I see that Peter Duniho gave you these same answers in
>> .DotNet.Framework...
>>
>

> 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.

"Anthony Lopez" <arlo***@charter.net> wrote in message
news:C6373C05.2AE9%arlopez@charter.net...
>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.
>