The process cannot access the file error on Vista but not Win 8.1

I'm having a bit of trouble with a File System Watcher and what looks like Windows Vista. My project has been built on Windows 8.1 as an Administrator and shows no signs of these error messages I get when I try and run this process on Vista.

The below is my FSW that runs at system start up

Code:

---

Sub MFW()


        If lstMessage.InvokeRequired Then
            lstMessage.BeginInvoke(New MethodInvoker(AddressOf MFW))
        Else

            watchfolder = New System.IO.FileSystemWatcher()

            watchfolder.Path = My.Settings.Out

            watchfolder.Filter = "*.txt"

            watchfolder.NotifyFilter = NotifyFilters.FileName

            lstMessage.BeginUpdate()

            AddHandler watchfolder.Created, AddressOf MessageArray
            AddHandler watchfolder.Deleted, AddressOf MessageArray

            lstMessage.EndUpdate()

            watchfolder.EnableRaisingEvents = True

        End If

End Sub

---

This then calls the below

Code:

---

Sub MessageArray()

    If lstMessage.InvokeRequired Then
        Me.lstMessage.BeginInvoke(New MethodInvoker(AddressOf MessageArray))
    Else
        Try
            With My.Settings.Out
                Dim outMail As String = My.Settings.Out
                lstMessage.Items.Clear()

                ReDim CISmsg(0 To 0)
                t = 0
                Dim cTxt As New IO.DirectoryInfo(outMail)
                Dim hello = cTxt.GetFiles("*.txt")
                ReDim CIStxt(hello.Count - 1)

                For Each InfoFile In (hello)
                    Dim Lines() As String = File.ReadAllLines(InfoFile.FullName)

                    CIStxt(t) = New Filedetail1()

                    CIStxt(t).mName = Path.GetFileNameWithoutExtension(InfoFile.Name)



                    Dim mline = Lines.Where(Function(x) (x.StartsWith("status="))).SingleOrDefault()
                    If mline IsNot Nothing Then
                        CIStxt(t).mStatus = mline.Split("="c)(1)
                    End If

                    Dim mlines = Lines.Where(Function(x) (x.StartsWith("date="))).SingleOrDefault()
                    If mlines IsNot Nothing Then
                        CIStxt(t).mDate = mlines.Split("="c)(1)
                    End If

                    If CIStxt(t).mStatus = "success" Then
                        lstMessage.Items.Add(CIStxt(t).mName, 0)

                    ElseIf CIStxt(t).mStatus = "fail" Then
                        lstMessage.Items.Add(CIStxt(t).mName, 1)

                    ElseIf CIStxt(t).mStatus = "received" Then
                        lstMessage.Items.Add(CIStxt(t).mName, 2)

                    End If

                    lstRequired.DataSource = Nothing
                    lstRequired.DataBindings.Clear()
                    t = t + 1
                Next
            End With
        Catch ex As Exception
            MsgBox(ex.Message)
        End Try
    End If

End Sub

---

If i remove the Try, Catch, End Try then I get a system generated error message as opposed to a message box so I'm confident its this code.

The error i'm getting is `The process cannot access the file because its being used by another process'

I'm a bit baffled as, like I say, it doesn't throw this error on Win 8.1

Cross posted here http://stackoverflow.com/questions/2...ut-not-win-8-1

My guess would be that you're trying to access a file that has just been created and it hasn't been released by the creator at that stage on Vista while on Win8 it has. I haven't used the FSW much but, in one case that I did, it was within the one system so I created files with a temp extension and then changed it when the file was full. That way, I could react to the rename rather than the creation and avoid that issue.

As a means of diagnosis at least, try reading the file in a loop with a 1 second delay between attempts. That way, it will keep on trying until the file is released and eventually read the file. If that works then you know that I'm on the right track and decide whether to stick with my suggestion or find a more robust solution.

Yeah, we ran into a similar issue back when with the FSW... we were watching a folder that clients accessed via FTP (to them it was an FTP folder, to us it was a regular folder) and what we found is that as soon as the file is created, the event fires off (as it should) but that doesn't mean that the process (what ever it may be) is done copying the file. What we did was to toss the file name into a Queue, and start a timer (or restart it if it was already going) wait 10 seconds (trial and error showed that it took an average 7 seconds to transfer the file, so 10 gave us a buffer), then process the file(s) in the queue.

One thing to look at... if I remember right, the FSW events do send over an EventParams object that will give you the name of the file affected, so you wouldn't need to scan the folder again with GetFiles.


-tg