• 0

[VB.NET]Copy File with progress bar


Question

I'm attempting to make a program that will copy files reclusively in VB.NET.

basically I have a function that calculates the total size of every file in the directory and sub directories then goes through all of them and calls the CopyFile function.

this works alright in that my progress bar actually updates while the file is being copied instead of using filenames like I had been. It just seams to be going a lot slower. Five seconds for a 156k file as opposed to bellow three.

Is there a better way?

Clint

        Private Function CopyFile(ByVal OldFile As String, ByVal NewFile As String)
            Me.FileProgressbar.Value = 0
            Dim FS As New FileStream(OldFile, FileMode.Open)
            Dim FW As New FileStream(NewFile, FileMode.CreateNew)
            Dim Buffer() As Byte
            'Get the bytes from file to a byte array
            ReDim Buffer(FS.Length - 1)
            Me.FileProgressbar.Maximum = FS.Length
            FS.Read(Buffer, 0, Buffer.Length)
            'Do your stuff :-)
            For i As Int32 = 0 To Buffer.Length - 1
                Me.FileProgressbar.Value += 1
                FW.WriteByte(Buffer(i))
                Me.TotalProgressbar.Value += 1
            Next
            FS.Close()
            FW.Close()
        End Function

Link to comment
https://www.neowin.net/forum/topic/341607-vbnetcopy-file-with-progress-bar/
Share on other sites

11 answers to this question

Recommended Posts

  • 0

I'm already using basic multi threading.

Per another board I changed it to write and update the progressbars every kb and that helped a lot.

It copied a 75.5 Meg file 1.53125 Seconds faster then File.Copy :)

I will try and get this "Proper Threading" thing figured out in the morning after I've had some rest. :p

Clint

  • 0

Yes I was, now it copies each Kb

My Code with a single progressbar took 42.374 seconds to copy a 483,005 kb file, File.Copy took 46.343 seconds

two progressbars:

My Code: 68.28 Seconds

File.Copy: 37.343 Seconds

No Progressbars:

Mine: 23.796 Seconds

.NET: 41.499 Seconds

that last one surprised me.

figured that at best mine would be just as fast as File.Copy, but apparently not...

Clint

  • 0
  GoodOlClint said:
Yes I was, now it copies each Kb

My Code with a single progressbar took 42.374 seconds to copy a 483,005 kb file, File.Copy took 46.343 seconds

two progressbars:

My Code: 68.28 Seconds

File.Copy: 37.343 Seconds

No Progressbars:

Mine: 23.796 Seconds

.NET: 41.499 Seconds

that last one surprised me.

figured that at best mine would be just as fast as File.Copy, but apparently not...

Clint

586183376[/snapback]

You seems calculating the time taken by using codes WHICH slows the copying process, if so then you should remove this codes and see the difference ;)

  • 0
  Elagizy said:
You seems calculating the time taken by using codes WHICH slows the copying process, if so then you should remove this codes and see the difference  ;)

no I used this to get how long it took:

Sub debug()
        Dim copy As New clsCopyFiles(Me.ProgressBar2, Me.ProgressBar1, Me.Label8, Me.Label7)
        Dim start1 As Date = Now
        copy.CopyFile("C:\largefile.wmv", "C:\video1.wmv")
        Dim finish1 As Date = Now
        Dim start2 As Date = Now
        File.Copy("C:\largefile.wmv:\video2.wmv")
        Dim finish2 As Date = Now
        MsgBox(finish1.TimeOfDay.TotalSeconds - start1.TimeOfDay.TotalSeconds & vbNewLine & finish2.TimeOfDay.TotalSeconds - start2.TimeOfDay.TotalSeconds)
    End Sub

so I wasn't calculating untill after the copying was done.

Clint

  • 0
  GoodOlClint said:
no I used this to get how long it took:

Sub debug()
        Dim copy As New clsCopyFiles(Me.ProgressBar2, Me.ProgressBar1, Me.Label8, Me.Label7)
        Dim start1 As Date = Now
        copy.CopyFile("C:\largefile.wmv", "C:\video1.wmv")
        Dim finish1 As Date = Now
        Dim start2 As Date = Now
        File.Copy("C:\largefile.wmv:\video2.wmv")
        Dim finish2 As Date = Now
        MsgBox(finish1.TimeOfDay.TotalSeconds - start1.TimeOfDay.TotalSeconds & vbNewLine & finish2.TimeOfDay.TotalSeconds - start2.TimeOfDay.TotalSeconds)
    End Sub

so I wasn't calculating untill after the copying was done.

Clint

586183620[/snapback]

The problem with your method, though, is that you can only transfer files that can fit in memory. Unless you are now implementing a buffer that outputs every megabyte or so.

  • 0

It's strange that you're like trying to reinvent the wheel, i mean yeah the base class library offers a static file copy method for you to use, why try to do it all over again, and furthermore, i'm sure their implementation of file copy is much more efficient.

  • 0
  Winston said:
It's strange that you're like trying to reinvent the wheel, i mean yeah the base class library offers a static file copy method for you to use, why try to do it all over again, and furthermore, i'm sure their implementation of file copy is much more efficient.

586185592[/snapback]

hehe I'm one of those people who can't stand knowing things work. I have to know why it works.

I learn best by reinventing the wheel. :-p

Besides, I'm in highschool, I can do anything right :shifty: ?

Clint

  • 0
  GoodOlClint said:
hehe I'm one of those people who can't stand knowing things work. I have to know why it works.

I learn best by reinventing the wheel. :-p

Besides, I'm in highschool, I can do anything right :shifty: ?

Clint

586185657[/snapback]

Yeah i guess it's good to understand how things work. But i think that's how you'd do it in general, however, i think the file.copy in which the framework provides, invokes a Win32 API, and i'm pretty sure MS does the file copy a little different, peraps more efficient, since they made the OS after all.

  • 0
  Winston said:
Yeah i guess it's good to understand how things work. But i think that's how you'd do it in general, however, i think the file.copy in which the framework provides, invokes a Win32 API, and i'm pretty sure MS does the file copy a little different, peraps more efficient, since they made the OS after all.

586186072[/snapback]

Oh I have no doubt that it is extremly more efficient. after all, they are a mega corp with billions to spend and I'm a 17 year old with $5 in my pocket...

Clint

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Tariffs have nothing to do with this pricing. It was always intended to be slightly more expensive then the S25+
    • Hello, The static link still downloads 10.3.2040.0 from May 22, 2025. The 10.3.2412.0 version can be downloaded directly from emclient.com/dist/v10.3.2412/setup.msi. Regards, Aryeh Goretsky
    • Hello, Yes, and yes. More specifically, there are lots of features in Windows that I do not use--I cannot recall the last time I needed to run EUDCEDIT.EXE or ODBCAD32.EXE on a computer I own, but I'm sure that for some people they are useful, and for a smaller set of people they might even be indispensable. I don't begrudge Microsoft for including them as part of the standard Windows installation nor the people who need such tools; sometimes it is convenient to have some little utility or feature readily available. One thing I do begrudge is Microsoft's over-reliance on its own telemetry, and perhaps surpisingly on the flip side, customers who disable it. Collecting telemetry is generally a good thing, if it is done for good reasons and does not include any customer PII. However, how you interpret that telemetry is even more important, as that can lead to all sorts of disastrous decisions. On the customer side of things, telemetry is your "vote:" it's how you tell companies what features you use in the program, and lets them prioritize things appropriately. One glaring example is Windows 8, which shipped with the full-screen Start Screen because Microsoft's telemetry told them the average Windows user pressed the Windows key to bring up the Start Menu less than once a day. I have often wondered how many "power users" of previous versions of Windows (XP, Vista, and 7) that relied on the Start Menu disabled the telemetry that would have told Microsoft a difference story about its usage. More recently, I came across a young lady who had a problem with a third-party sync program on her computer running Windows 7. An update for the utility removed Windows 7 compatibility, and broke her backup process. Now, support for Windows 7 ended over 5 years ago in 2020, but there are ISVs who still support their software on it, but decisions about stuff like that are made, in part, by knowing what percentage of your customer base is on what operating system version. When I asked about that, she mentioned she had specifically disabled the telemetry from the sync program to its developers, which was optional to begin with. What made things even worse was that this was an open source utility, and its authors had a very clear, well-designed and scoped policy on the telemetry they collected, the pains they went through to avoid collecting any PII, and even other ancillary risks involving information disclosure (like just using of the software) because of the network connection made for the checks. Yet, she took herself out of telling the project maintainers "Hey, I use your software and I'm running Windows 7" by disabling the telemetry checks, which could have let them know they needed to continue supporting it. In a sense, sending telemetry is just like voting: Individually, you may not think it matters much, but it is often the basis for very important decisions. Regards, Aryeh Goretsky
    • Hello, My thoughts on this are mixed. Microsoft has hosted malicious code in the Microsoft Update Catalog where third party device drivers are stored; I wrote about one such incident about fifteen years ago, so if there are any other old malicious drivers floating around in the catalog, this will be a good step towards preventing any infestations from reoccurring. Another thing, which surprisingly is not mentioned in Microsoft's announcement, is that this helps protect against BYOVD (Bring Your Own Vulnerable Driver) attacks, where malware either comes with or downloads an older device drivers with vulnerabilities in it that can be exploited to gain access to kernel memory. Removing all those old device drivers from the Windows Update Catalog, potentially with all sorts of undisclosed vulnerabilities in them, means an attacker can no longer leisurely count on being able to download them from Microsoft's servers--something that may go unnoticed or ignored by security analysts. This makes the adversary attack a little more noisy, since they have to either include the device driver with the rest of their initial payload or download it from a third-party site at some point prior to beginning their BYOVD attack. On the other hand, it means that people who are looking for a specific version of an older device driver for whatever legitimate reasons, like compatibility, performance or stability, may end up going to dodgy third-party sites in search of older drivers, which increases the risk of exposure to everything from nuisance advertisements and unwanted software to actual malicious code. As for me, I have keeping copies of all the device drivers, firmware updates, etc. I have downloaded over the years, some dating back to DOS and Windows 3.x era, not just for hardware I won, but popular things like unified chipset and video card drivers, just in case I ever needed it. It might seem silly to collect such a thing, but the hardware drivers, firmware updates, and documentation are just about 2 TB in size. From my perspective, it is an inexpensive form of insurance, especially given that disk space is always getting cheaper over time. Regards, Aryeh Goretsky
    • @Raze Bold it boy. (I admit, we all did it from time to time..)
  • Recent Achievements

    • Contributor
      GravityDead went up a rank
      Contributor
    • Week One Done
      BlakeBringer earned a badge
      Week One Done
    • Week One Done
      Helen Shafer earned a badge
      Week One Done
    • First Post
      emptyother earned a badge
      First Post
    • Week One Done
      Crunchy6 earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      660
    2. 2
      ATLien_0
      266
    3. 3
      Michael Scrip
      235
    4. 4
      Steven P.
      164
    5. 5
      +FloatingFatMan
      149
  • Tell a friend

    Love Neowin? Tell a friend!