Multithreading Backup Utility

• Download Backup - 844.99 KB
• Download Source - 254.66 KB

Introduction

Backup is a utility program that will copy files from one path to another using one thread to display the names of the files being copied, and another thread to count the number of files and folders at the same time the files are being copied. This means no time is wasted waiting to get the file count before the copy can start; it copies and counts at the same time using two threads.

The Backup application is also a handy utility to copy large volumes of files from one path to another quickly and efficiently. It is fast simply because it will not copy a file that is already in the destination path and has not changed (why copy a file that is already there and hasn't changed?). So it's great for repetitive backups as it only copies new or updated files.

Another added feature is that Backup will not stop copying just because it got a security error on a particular file, or any type of error for that matter (excluding a hardware failure, of course). It will simply log the error and keep going until finished. You can then review the errors in the log file afterwards, which will show the error and the file that failed to copy. Most failures are due to security configuration problems.

Background

If you just want the Backup utility, then there is no need to read on as the rest of this article is a technical discussion on multithreading or threading. The download links are at the top left corner of this page.

So why use threading? One reason may be because you want to be able to press a button on the form while the form is busy but it won't let you because it's busy. The old VB6 way of doing this is to use a Timer perhaps, or use Do Events at regular points in the code while processing. I doubt that Do Events will work for this purpose in VB.NET and although a Timer may solve the problem, there are other reasons to get familiar with threading.

Another reason is that with dual/multi core processing now available and true multitasking at the hardware and operating system level, threading is going to be hard to avoid, especially when performance is a concern and your application is processor intensive.

Okay, so you have decided you want to do threading in .NET. You could use the BackgroundWorker (Windows Form control), but I suspect you should start with the System.Threading namespace and use the Thread class directly. My personal view is that the Thread class is easier to use and gives you more flexibility although the BackgroundWorker will remove some of the grunt programming work.

So what is a thread anyway? Simply put, it is the equivalent to another completely separate program that is initiated from your main program. Once a thread is started, the main program does not know anything about the thread (or threads); they are effectively separate programs in their own right. So some of the first things you may want to know are how to create them, how to pass data between them, how to call the main application from a thread and finally, how does the main application know which thread has called it?

Viewing the code snippets below should help answer these questions.

One final point before we start, using threads to copy files is not necessarily the best application of multithreading as copying files is disk I/O intensive rather than processor intensive. But it's still a fair use as counting files and copying files can occur asynchronously rather than synchronously, so why wait? And besides that, I think Backup is a simple and handy utility at the same time.

Using the Code

This description of the code will not discuss the finer points of how to copy files but simply show the relevant source code to create the threads and use them from the main form application; showing how the threads are created and how parameters can be passed from the threads to the main Windows forms application.

First, take a quick look at the imported namespaces in the Backup form:

Imports System.Threading
Imports System.IO
Imports System.Diagnostics.Process

The System.Threading namespace is imported so you can create a Thread class for each thread. The System.IO namespace for file operations and the System.Diagnostics.Process is used to view the log file with Notepad.

The next code snippet from the Backup utility shows the declaration of a FileCopy class called CopyFiles in the main Windows form:

Imports System.Windows

Public Class Backup

    ' Declare the FileCopy class.
    ' This class will create 3 threads to copy, count and mirror files
    ' and raise events for each, so the events must be handled
    ' to update the form with status data.
    Dim WithEvents CopyFiles As FileCopy

    Private Sub StartCopy_Click(ByVal sender As System.Object, e As System.EventArgs) _
        Handles StartCopy.Click

        ' Create the FileCopy class which will initiate the threads
        CopyFiles = New FileCopy

        ' Initiate the copy, count and mirror threads from the FileCopy class
        CopyFiles.StartCopy()

    End Sub
    .
    . remaining forms code
    .
End Class

Pressing the Go button on the Backup form will initiate the StartCopy_Click subroutine. This subroutine will instantiate the FileCopy class as CopyFiles and then use the CopyFiles.StartCopy() method to begin the copy.

So far, all we have done in the main Windows form is declare as class, instantiate it, and then execute the StartCopy() method. So why have we created a class? Is it just good OOD practice?

And where is the code that declares the threads and starts them? Well, the very important point I am trying to make here, is that if you want to use threads, then it's best to create a class and use that class to start the threads. This is because the class can raise events whenever the threads it initiates need to communicate with the parent thread.

This might seem obvious for the well rehearsed (and the arrogant) , but it's a very important design consideration, i.e. use a class to start threads.

Okay, now let's look at the FileCopy class, and see how it starts the threads:

Imports System.IO

Public Class FileCopy

    ' Declares the variables you will use to hold your thread objects.
    Public CopyThread As System.Threading.Thread
    Public CountThread As System.Threading.Thread
    Public MirrorThread As System.Threading.Thread

    Public Sub StartCopy()

        ' Sets the copy and count threads using the AddressOf the subroutine where
        ' the thread will start.
        CopyThread = New System.Threading.Thread(AddressOf Copy)
        CopyThread.IsBackground = True
        CopyThread.Name = "Copy"
        CopyThread.Start()

        CountThread = New System.Threading.Thread(AddressOf Count)
        CountThread.IsBackground = True
        CountThread.Name = "Count"
        CountThread.Start()

    End Sub
    .
    . code for the rest of the class
    .
End Class

Pretty simple huh? Declare the threads and then have a method start them. So far, so good. But now that we have started the CopyThread and the CountThread, how do we get them to "talk to" the Backup form by passing parameters? How will the Backup form know which thread is doing what? These are reasonable questions when you consider threads run in their own address space and don't know about each other.

If you note the use of the AddressOf operator when instantiating the threads, you will see that each thread is assigned to a private subroutine in the FileCopy class called Copy and Count, respectively. All you really need to do is have your code raise events in these subroutines whenever they want to communicate with the main parent thread (the parent thread is the Backup windows form control/class).

Let's look quickly by expanding the FileCopy class and see how this is done:

Imports System.IO

Public Class FileCopy

    ' Declare the events that will be raised by each thread
    Public Event CopyStatus(ByVal sender As Object, ByVal e As BackupEventArgs)
    Public Event CountStatus(ByVal sender As Object, ByVal e As BackupEventArgs)
    Public Event MirrorStatus(ByVal sender As Object, ByVal e As BackupEventArgs)

    ' Declares the variables you will use to hold your thread objects.
    Public CopyThread As System.Threading.Thread
    Public CountThread As System.Threading.Thread
    Public MirrorThread As System.Threading.Thread

    ' Class variables' Class variables
    Private _filePath As String
    Private _fileSize As String
    Private _copiedFolders As Long
    Private _copiedFiles As Long
    Private _countedFolders As Long
    Private _countedFiles As Long
    Private _mirroredFolders As Long
    Private _mirroredFiles As Long
    .
    . even more class variables but we will just show the relevant ones.
    .

    Public Sub StartCopy()

        ' Sets the copy and count threads using the AddressOf the subroutine where
        ' the thread will start.
        CopyThread = New System.Threading.Thread(AddressOf Copy)
        CopyThread.IsBackground = True
        CopyThread.Name = "Copy"
        CopyThread.Start()

        CountThread = New System.Threading.Thread(AddressOf Count)
        CountThread.IsBackground = True
        CountThread.Name = "Count"
        CountThread.Start()

    End Sub

     Private Sub Copy()
        .
        . this is a program loop with logic to copy files
        .
        Loop to Copy Files

            Copy a file here

            ' Raise the copy status event at the end of the program loop
            RaiseEvent CopyStatus(Me, New BackupEventArgs_
                    ("", 0, _copiedFiles, _copiedFolders))
            Threading.Thread.Sleep(1)
        End Loop

      End Sub

      Private Sub Count()
        .
        . this is a program loop with logic to count files
        .
        Loop to Count Files

            Count a file here

            ' Raise the count status event at the end of the program loop
            RaiseEvent CountStatus(Me, New BackupEventArgs_
                    ("", 0, _countedFiles, _countedFolders))
            Threading.Thread.Sleep(1)
        End Loop

    End Sub
    .
    . code for the rest of the class
    .
End Class

So, there you have it. A basic class declaration that starts threads and raises events whenever it needs to communicate with the main parent thread, (which we know is the Backup Windows form control).

Note the use of Threading.Thread.Sleep. This is needed to allow the parent thread time to do its thing, like refresh the form display and respond to button clicks. Pretty cool so far, but we are not quite there yet.

We now need to look at the main parent thread (the Backup Windows form control) and see the code needed to pass those parameters.

First, take note the e parameter in the declaration for the events in the code snippet above. The e parameter is a variable of a custom class called BackupEventArgs that has four parameters called FilePath, FileSize, FileCount and FolderCount. This custom class inherits from EventArgs and is just a standard way to declare parameters for events. You could have just as easily declared a separate variable for each of the parameters instead of making a custom class to contain the parameters. To see what the BackupEventArgs class is all about, please refer to the source code, as how you declare parameters for events is a little outside the scope of this article.

For now, just consider that the e variable contains the parameters (FilePath, FileSize, FileCount and FolderCount) that we want to pass to and process in the main parent thread.

So, let's focus back on the parent thread, and let's see the code that deals with the events:

Imports System.Windows

Public Class Backup

    ' Declare the FileCopy class. This class will create 3 threads to copy, 
    ' count and mirror files
    ' and raise events for each, so the events must be handled to update
    ' the form with status data.
    Dim WithEvents CopyFiles As FileCopy

    ' Declare delegate handlers for the copy and count events
    Public Delegate Sub CopyHandler(ByVal FilePath As String, _
            ByVal FileSize As Long, ByVal FileCount As Long)
    Public Delegate Sub CountHandler(ByVal FileCount As Long, ByVal FolderCount As Long)
    .
    . more declarations
    .
    Private Sub StartCopy_Click(ByVal sender As System.Object, _
            ByVal e As System.EventArgs) Handles StartCopy.Click

        ' Create the FileCopy class which will initiate the threads
        CopyFiles = New FileCopy

        ' Initiate the copy, count and mirror threads from the FileCopy class
        CopyFiles.StartCopy()

    End Sub

     Private Sub CopyStatus(ByVal FilePath As String, ByVal FileSize As Long, _
            ByVal FileCount As Long)
        .
        . some code to update the forms display
        .
    End Sub

    Private Sub CopyFiles_CopyStatus(ByVal sender As Object, _
            ByVal e As BackupEventArgs) Handles CopyFiles.CopyStatus
        ' BeginInvoke causes asynchronous execution to begin at the address
        ' specified by the delegate. Simply put, it transfers execution of
        ' this method back to the main thread. Any parameters required by
        ' the method contained at the delegate are wrapped in an object and
        ' passed.

        Me.BeginInvoke(New CopyHandler(AddressOf CopyStatus), _
                New Object() {e.FilePath, e.FileSize, e.FileCount})

    End Sub
    .
    . remaining forms code
    .
End Class

The code snippet above has a CopyFiles_CopyStatus() event that is added to the main form (parent thread) when the CopyFiles variable is declared using WithEvents. It uses the Me.BeginInvoke method of the form control to pass the parameters from the CopyThread to the parent form thread. All Windows controls, including the forms control, have a BeginInvoke method for asynchronous execution, (and an Invoke method for synchronous execution), that allow you execute the specified delegate.

In the code above, the specified delegate is CopyHandler which is assigned to the CopyStatus subroutine using the AddressOf operator. When the CopyFiles_CopyStatus() event occurs, it passes the parameters back to the main parent thread (the Backup Windows form control) by executing the CopyStatus() subroutine via the delegate, asynchronously.

If I have left you confused, just consider that although it looks like the CopyFiles_CopyStatus() event is occurring in the Backup windows form control/class, it actually isn't. It's really occurring in the CopyThread thread, which is a separate bit of code in its own right that doesn't know about the parent thread. A difficult concept to grasp when the event in question is declared in the Windows form control class, but that's how it works.

Moving on, (for those still with me), just a couple of pointers that will help if you are new to threading. If we revise the FileCopy class code snippet below to include the Join method that is available on a thread, we can make one thread wait for another thread at a point in the code.

One problem (challenge actually) I had was that I needed to make the copy thread wait for the count thread to complete before it (the copy thread) terminates naturally (i.e. finishes copying files). You would expect the count thread to finish first, but when there are no files to copy, sometimes the copy thread finished first!

Using the join method allows me to deal with this situation. So remember the Join method if one thread depends on, and must wait for, the completion of another:

Imports System.IO

Public Class FileCopy

    ' Declare the events that will be raised by each thread
    Public Event CopyStatus(ByVal sender As Object, ByVal e As BackupEventArgs)
    Public Event CountStatus(ByVal sender As Object, ByVal e As BackupEventArgs)
    Public Event MirrorStatus(ByVal sender As Object, ByVal e As BackupEventArgs)

    ' Declares the variables you will use to hold your thread objects.
    Public CopyThread As System.Threading.Thread
    Public CountThread As System.Threading.Thread
    Public MirrorThread As System.Threading.Thread

    ' Class variables' Class variables
    Private _filePath As String
    Private _fileSize As String
    Private _copiedFolders As Long
    Private _copiedFiles As Long
    Private _countedFolders As Long
    Private _countedFiles As Long
    Private _mirroredFolders As Long
    Private _mirroredFiles As Long
    .
    . even more class variables but we will just show the relevant ones.
    .

    Public Sub StartCopy()

        ' Sets the copy and count threads using the AddressOf the subroutine where
        ' the thread will start.
        CopyThread = New System.Threading.Thread(AddressOf Copy)
        CopyThread.IsBackground = True
        CopyThread.Name = "Copy"
        CopyThread.Start()

        CountThread = New System.Threading.Thread(AddressOf Count)
        CountThread.IsBackground = True
        CountThread.Name = "Count"

        CountThread.Start()

    End Sub

    Private Sub Copy()
       .
       . this is a program loop with logic to copy files
       .
       Loop to Copy Files

           Copy a file here

           ' Raise the copy status event at the end of the program loop
           RaiseEvent CopyStatus(Me, New BackupEventArgs_
               ("", 0, _copiedFiles, _copiedFolders))
           Threading.Thread.Sleep(1)
       End Loop

       ' After all files have been copied, cause this CopyThread to wait 
       ' until CountThread has finished
       If CountThread.IsAlive Then CountThread.Join()

     End Sub

     Private Sub Count()
       .
       . this is a program loop with logic to count files
       .
       Loop to Count Files

           Count a file here

           ' Raise the count status event at the end of the program loop
           RaiseEvent CountStatus(Me, New BackupEventArgs_
                   ("", 0, _countedFiles, _countedFolders))
           Threading.Thread.Sleep(1)
       End Loop

   End Sub
   .
   . code for the rest of the class
   .
End Class

And one final pointer. How do you terminate a thread? Using the Abort method is frowned upon by some, although there is some consensus that it's okay to use if aborting the whole application, some purists believe it should be deprecated for technical reasons relating to how resources are allocated and unallocated during execution. In other words, you should signal the thread to terminate itself rather than aborting it when its in the middle of something.

The code snippet below shows a method called StopThreads() in the FileCopy class that simply sets a boolean class variable called _stopNow to True. When the StopThreads() method is executed from the parent thread (Backup), all any threads have to do is check _stopNow and exit the processing loop to terminate the thread nicely, as shown in the Copy subroutine code snippet below (which has been assigned to the copy thread as we saw earlier):

Public Class FileCopy
    .
    . class code
    .
    Public Sub StopThreads()

        _stopNow = True

    End Sub
    .
    . more class code
    .
    .
    Private Sub Copy()

        While Loop to copy files

            If _stopNow Then
                Exit While
            End If

            copy a file
            raise an event to notify parent thread

        End While

    End Sub
    .
    .
    .
End Class

Points of Interest

Much of the code above was developed by copying and adapting code from the MSDN. So if you really want to get into the finer points of threading, there are some very fine examples that have been well explained at msdn.microsoft.com.

I must say that the MSDN is finally improving to the point where it's hard not to be impressed. Some of the articles there even discuss best practice at length with some very fine walkthroughs. So a very special thanks to the coding gurus at MSDN.

And finally, in saying goodbye and thank you to those that have managed to read this far, please vote for my article, be generous and you will be rewarded in kind.

History

October 2007

Uploaded version 1.0.7 which contained bug fixes as well as added a batch mode for running without a form and processing command line parameters.

June 2008

Uploaded version 2.0.0 which is a complete revision of the source code and this article, also added a help file and a mirror copy feature.

July 2008

Uploaded version 2.1.0 which has a new mini status bar as well as some fixes to some faults that may surface in version 2.0.0. So please upgrade.

Also note that so far Backup has not been tested on Windows Vista. You may try it on Vista and, if there are problems, check back here periodically as there should be another release over the next few months that will be tested on Vista.

Upgrading to the Latest Version

If upgrading from a previous version, please uninstall the previous version first. Do this from the Control Panel (Start/Control Panel) by double clicking the Add/Remove Programs icon and selecting Backup from the list.

Using the Latest Source Code

The source code for Backup version 2 was created using Visual Studio 2008 and the .NET Framework 3.5, so older versions of Visual Studio are likely to have compatibility issues.

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 25 of 33 (Total in Forum: 33) (Refresh) FirstPrevNext

Subject   Author  Date  ReparsePoints on Vista Dennis Micheelsen 10:16 8 Jul '08   I would suggest that the copy routine checks if it encounters any ReparsePoints in the directory structure... I've done this in an none generic way, as i'm atm. only using it to backup my users dir. on my vista box .. and it got reparsepoints in c:\users\<username>\appdata\local\ (actually it's "Application Data" that is sinner : ) If (New DirectoryInfo(_filePath.Substring(0, _filePath.LastIndexOf("Application Data"))).Attributes And FileAttributes.ReparsePoint) &lt;&gt; 0 Then Continue For End If As i said this in no way generic enough for system wide use .. I'm thinking that some sort of RegEx could do the trick .. but not at all sure . Regards Dennis Sign In·View Thread·PermaLink Re: ReparsePoints on Vista Taner Riffat 1:29 9 Jul '08   Dear Dennis Thanks for letting me know. I have heard Vista may cause problems, particularly when trying to write application data. So I will definately do some homework regarding ReparsePoints. I expect to test on Vista over the next month and will post here when I do and let you know what happens. I will do another release that is Vista compatible within a month or two. Thanks again. Taner. You can contact me at howartthou@hotmail.com. Regards Taner Sign In·View Thread·PermaLink Perhaps try one thread for source drive and one for destination? supercat9 16:09 3 Jul '08   The source-drive thread could read files into RAM and then make them available for the destination-drive thread which would write them to the target. It would be necessary to add an check to ensure that the amount of information read into RAM was reasonable, since otherwise the source thread might get too far ahead of the destination-drive thread. Sign In·View Thread·PermaLink Re: Perhaps try one thread for source drive and one for destination? Taner Riffat 21:12 3 Jul '08   Supercat9 A very, very interesting approach. This has potential to speed up the copying and really leverage off threading. Would definately need to track the RAM as you suggest. Perhaps if I could do it all again I would try your idea, but for now I just do not have the time. I have decided to just stick to bug fixes for the time being, but will remember your tip. Thanks very much. Regards Taner You can contact me at howartthou@hotmail.com. Regards Taner Sign In·View Thread·PermaLink Great! schadepde 2:19 15 Dec '07   I like such programs! Backup does exactly what it should do. Starts immediately, reacts promptly and continues without break (unlike XCopy on our network). The code stimulates to think more often of multithreading as alternative to straight forward coding. Thanks, SuperCoder! Sign In·View Thread·PermaLink Re: Great! SuperCoder! 18:25 16 Dec '07   Thanks for the positive feedback schadepde Stay tuned as I am working on Backup version 2.0 which will have the option to mirror the source folder... You can contact me at howartthou@hotmail.com. Regards SuperCoder! Sign In·View Thread·PermaLink Command Line Arguments - Minor Bug SuperCoder! 19:52 29 Oct '07   Hi All When using command line arguments: 1. If the source path does not exist Backup will just terminate and not produce an error message or a log file. In the next release an error message will be written in the log file if the source path does not exist. 2. If the source path does exist, but the destination path doesn't, then Backup will create the destination path (provided the drive is a valid drive letter) and do the copy and produce a log file. The means if you entered "c:\mybackuppath" instead of "d:\mybackuppath" for the destination path, then all the files will get copied to the c drive because the destination path is valid. So, in brief, make sure the source and destination paths are correct and all will work as expected. Any questions? Please feel free to post them here. You can contact me at howartthou@hotmail.com. Regards SuperCoder! Sign In·View Thread·PermaLink Old files? LegoMindstorms 2:24 29 Sep '07   This is just a great program! There's only one point: If I delete a file, it isn't deleted in the backup folder. How can I implement this? http://www.t-tools.nl.tt/ Sign In·View Thread·PermaLink Re: Old files? [modified] Super Coder! 20:08 29 Sep '07   Hi LegoMindstorms Thanks for the compliment. This is a prototype application so the code isn't perfect and has only basic features. However there are a few choices if you want to ensure files deleted from the source folder are also deleted from the backup folder (in random order): 1. You could use the MS Backup utility that comes with Windows. Press Start/All programs/Accessories/System Tools/Backup from Windows. I don't use this program but have been told "it does everything" (whatever that means). 2. You could download the source code at the top of this page and modify this program for yourself. Admittedly you would need to be a programmer or at least know someone that will do it for you. 3. You could simply delete the destination backup folder before you do the backup. This would ensure deleted files do not exist when you do the backup again. Use option 3 at your own risk. The problem with this option is that all files will be copied again so the backup would run longer than usual. There is also a slight risk that if the hard drive that contains the original files crashed during the backup you will have only a partial backup or none at all. You could backup to a new destination first then delete your old destination... Hope this helps. You can contact me at coder@danhog.com or howartthou@danhog.com. Regards Super Coder! Sign In·View Thread·PermaLink Re: Old files? LegoMindstorms 23:29 29 Sep '07   Then I'm gonna try to modify the source code, I am a (beginning) programmer, so then I've got a challenge;P http://www.t-tools.nl.tt/ Sign In·View Thread·PermaLink Re: Old files? Super Coder! 18:51 17 Oct '07   Hey LegoMindstorms Thats a tall order for a beginner programmer. The problem you need to solve is how do you know which files have been deleted from the source path so you can then delete them from the destination path. One way would be to log all the files copied in the previous backup and then check to see if any are missing by comparing the logged files with whats in the current source path. You could even use a database to make retrieval of logged file info faster. Another way would be to save all the files you are copying for the current directory into an array then read all the files in the destination directory and if they are not in the array then delete them. There are probably a few more ways too. The trick is to find a solution that is as simple as possible and will not affect the performance (speed) or robustness of the application. I will think about it some more. Any ideas anyone? You can contact me at howartthou@hotmail.com. Regards Super Coder! Sign In·View Thread·PermaLink Re: Old files? LegoMindstorms 3:20 18 Oct '07   I've modified the countthreat to this: Private Sub Delfiles(ByVal FSInfo As FileSystemInfo()) If _del = True Then ' Check the FSInfo parameter. If FSInfo Is Nothing Then Throw New ArgumentNullException("FSInfo") End If ' Iterate through each item. Dim i As FileSystemInfo For Each i In FSInfo Try ' Check to see if this is a DirectoryInfo object. If TypeOf i Is DirectoryInfo Then ' Cast the object to a DirectoryInfo object. Dim dInfo As DirectoryInfo = CType(i, DirectoryInfo) ' Iterate (recurse) through all sub-directories. Delfiles(dInfo.GetFileSystemInfos()) ' Check to see if this is a FileInfo object. ElseIf TypeOf i Is FileInfo Then 'save the full path and file name Dim nameoffile As String = i.FullName 'Get the copy path name only Dim copypath As String = My.Computer.FileSystem.GetParentPath(nameoffile) ' Update status info on client Dim message As String 'Del copy path if it does not exist If Not Directory.Exists(copypath) Then Directory.Delete(FromPath & "\" & copypath.Replace(ToPath, "")) message = "Verwijderen: " & Environment.NewLine & FromPath & "\" & copypath.Replace(ToPath, "") CallClient(Thread.CurrentThread.Name, 0, 0, 0, message) End If ' if file exists check if file has been updated since last copy If Not File.Exists(nameoffile.Replace(ToPath, FromPath & "\")) Then File.Delete(nameoffile) message = "Verwijderen: " & Environment.NewLine & nameoffile CallClient(Thread.CurrentThread.Name, 0, 0, 0, message) End If If My.Computer.FileSystem.GetDirectoryInfo(copypath).GetFiles.Length = Nothing Then My.Computer.FileSystem.DeleteDirectory(copypath, FileIO.DeleteDirectoryOption.DeleteAllContents) message = "Verwijderen: " & Environment.NewLine & copypath CallClient(Thread.CurrentThread.Name, 0, 0, 0, message) End If End If Catch ex As Exception 'Record error then continue (like a resume next) WriteLog(ex.Message.ToString) End Try Next i End If End Sub You call the sub like this: ' Create a new DirectoryInfo object for from path. Dim dir As New DirectoryInfo(ToPath) ' Call the GetFileSystemInfos method. Dim FSinfo As FileSystemInfo() = dir.GetFileSystemInfos ' Count folder and files Delfiles(FSinfo) But I'm thinking where I need to call this, or if it can be simpler made... http://www.t-tools.nl.tt/ Sign In·View Thread·PermaLink Re: Old files? Super Coder! 20:41 18 Oct '07   Hey LegoMindstorms If I read your code correctly you read all the files in the "To Path" and you check to see if each file (and directory) is in the "From Path", and if not, you delete it from the "To Path". You could do this as another thread but that would mean it would compete with itself for disk I/O time. Probably not a good idea given that hard disk access is a bottleneck in this application. I suggest you do this first thing before the copy logic (when the "_del" parameter is set of course). This would be a synchronous task i.e. it must complete before the copy tasks start. To do this, you could introduce a new method called "DeleteRedundantFiles" and call that first and let it do it's thing. It will take longer but not too much longer as most disk I/O accesses would be reads and not deletes - reads are fastest. By the way, I have sent an update to CodeProject which has the latest release (version is 1.0.7). You should get the latest version first as it has bug fixes. Look out for a new "History" section at the end of the article which explains about the new version. If the new "History" section is not yet visible on this page then wait - it should appear anytime soon, hopefully within a week anyway... You can contact me at howartthou@hotmail.com. Regards Super Coder! Sign In·View Thread·PermaLink Re: Old files? LegoMindstorms 6:48 28 Oct '07   I've waited for the article to update, but my logfile is working properly, and the new features I don't need, I made kind-of myself. I hadn't to wait, but my deletefunction works now, thanks for that The result is Back!tUp (Dutch) Sign In·View Thread·PermaLink Nice little example - a few changes I thought useful RobbSadler 8:55 20 Jul '07   I thought this was a nice example and does a nice utilitarian job at the same time. I made a few changes to the code which I thought may be of interest. First, I changed the date comparison, in my backup directory, it is possible that once a file has gotten out there, that I may update it there. The backup utility was checking for "=" but not for newer files. Thus a newer file in the target would be overwritten by the backup, so I changed it: If File.GetLastWriteTime(_fileName) <= File.GetLastWriteTime(tofile) Then Second, the word finished was misspelled... ' If finished copying If Message = "END" Then lblStatus.Text = "Status: Copy Finished. Copied " + _ _totalFiles.ToString + " files in " + _ _totalFolders.ToString + " folders." Third, since I like to see a clearer indication of what's happening, and I get nervous (even when I have seen the code) when a program says its doing something it's not -- I changed the message display for the copy message. I moved it down to where we know if we are OkayToCopy, and deleted the "Copying:" from where it was in the code receiving the message so it just says: txtFile.Text = Message and the code that creates the message to (moved to the if stmt, and Message Dim'd at top of sub): ' Copy file with overwrite If OkayToCopy Then Message = "Copying: " & Environment.NewLine & _ _fileName & " is " & _ Decimal.Round(CDec(fi.Length / 1048576), 2) & _ "MB in length." CallClient(Thread.CurrentThread.Name, _copiedFiles, _ _totalFiles, _directories, Message) File.Copy(_fileName, tofile, True) Else Message = "Skipping: " & Environment.NewLine & _fileName CallClient(Thread.CurrentThread.Name, _copiedFiles, _ _totalFiles, _directories, Message) End If This way it say "skipping" instead of "copying" when it is skipping, a clear indicator of what's being skipped. I also added a newline in the string so that it the path wouldn't jump around when changing from skipping to copying (for those of us watching the progress intensely). Thanks for a fun and useful little example of multithreading! Sign In·View Thread·PermaLink Re: Nice little example - a few changes I thought useful [modified] Super Coder! 19:37 20 Jul '07   Thanks Robbsadler. Its nice to get some positive feedback. Expectations here run high. The code is far from perfect and all your suggestions are good ones. I have fixed some of the errors but have not published it here yet. I also want to rewrite the whole code using a more oo best practice approach. It's really just proto-type code at the moment...maybe I will get round to it one day. Thanks again!