• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 579
  • Last Modified:

Visual Basic File Copy Procedure Freezes when Network Goes Down


I have the need (let's just assume my reasoning is sound on why I want this the way I am proposing, so please no comments like "why not buy such and such a program") to copy files across a VPN from 1 server to another and I want to do this with a Visual Basic App.  

I want this app to be fail safe, meaning if the VPN goes down and the program is in the middle of transferring files I want the program to timeout for a specfic amount of time and retry that file a set amount of times before it gives up and goes on to the next.  

I have tried numerous methods to test whether the network is up before attempting the Copy, such as FSO.isready function.  FSO.FileExists function,   Using semi-asycrounyous API Call to "CopyFileEx Lib".  To test the program I start the copying procedure and midway through the list I'll will disable my network connection.  Everyway I do it without fail the VB App freezes and cannot continue on.

One thought I had was writing a second app to do the actual coping, that way if it froze the main app could detect this close it and try again a certain amount of time later.  This 2nd helper app could check in each after completing each file or even be restarted for each file.

Is this last method viable before I waste my time tryign to configure it?

Do I need to find a completely Asyncrounous way of doing this so as to not freeze the main app?

Anybody have any thoughts on how to accomplish this in a way I have not thought about?

Any help is greatly appreciated from a point in the write direction to snipit's of code.

Thanks a million

  • 3
  • 2
1 Solution
Create ActiveX EXE that copies file. You can use timer control in ActiveX EXE if you want it to wok async. Or you can try something like this: http://www.vbaccelerator.com/home/VB/Code/Techniques/Finding_Which_DLL_Contains_an_API_Call/VB6_Async_File_Find_Component.asp
David LeeCommented:
I can think of two other possibilities.  First, create your own copy routine.  Open the file to be copied in binary mode, read in x number of bytes, and write them to the destination file at the distant end.  Before writing out each buffers worth of data you can test the connection and halt the process if it's gone.  Second, create a multi-threaded application.  Have the copy process run in it's own thread.  The main thread can monitor the network connection and terminate the copy thread if the connection is lost.
hausen4uAuthor Commented:

Thanks I will try those out when I get home tonight.


My biggest problem thus far is coming up with a way to test the network connection without having the program bomb if the result is negative.

Both IsReady and FileExists bomb if I pull the plug on a mapped network drive when it tests.  Perhaps if I use \\server\share instead of a mapped
drive then it wouldn't seize?  So the problem isn't that I especially want Asynch is that I can't figure out how to test the network before attempting
the file transfer.  Because all attemps thus far freeze the program if the network is unplugged.

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

David LeeCommented:
I can't imagine why IsReady or FileExists would bomb if the mapped drive is pulled.  I can run both against non-existent drives and they work fine.  I wrote the two functions below and used them in a test program I put together that executed both every 1.5 seconds.  I launched the test program and then cut my connection to my network.  They both ran on, each accurately reporting that the drive/file was no longer available.  I wonder if your program locked up as a result of the copy operation failing when the drive connection disappeared, rather than the connection test failing?  You might want to run a test and see if my tests fail too.  Otherwise, without seeing your code I can't really make an educated guess at what the problem might be.

Private Function StillConnectedA(strDriveLetter As String) As Boolean
    Dim objFSO As New FileSystemObject, _
        objDrive As Drive
    On Error GoTo NotConnectedA
    StillConnectedA = False
    Set objDrive = objFSO.GetDrive(strDriveLetter)
    StillConnectedA = objDrive.IsReady
    Set objDrive = Nothing
    Set objFSO = Nothing
End Function

Private Function StillConnectedB(strFileName As String) As Boolean
    Dim objFSO As New FileSystemObject
    On Error GoTo NotConnectedB
    StillConnectedB = False
    StillConnectedB = objFSO.FileExists(strFileName)
    Set objFSO = Nothing
End Function
hausen4uAuthor Commented:

Yeah you must have been correct on why my machine was bombing out.  I must have been checking for a True but then sending it through either way.  Stupid Rookie mistake.

But now I am intriqued into using a multi-threaded approach because of the single case where the program checks the file over the network sees it as connected starts the transfer then the network bombs.  If I was using a copier App on another thread then theoretically the helper app would bomb but the main app could see this and restart that file after network comes back online.  The parts that I'm not so sure I understand are:

1) how does the main app know when the helper bombs
2) and then how would the main app kill that instance of the active X

I believe if I could figure out those 2 parts then I could manage the rest of it.  If you could help me with those parts i'd appreciate it.  I'll award the points either way i just want to leave the question open for another day, see if anyone else has any helpful comments.

David LeeCommented:
Let me start off by saying that I haven't written any multithreaded programs myself.  I've just read about how it's done.  I'm encluding several links at the end of this post that will take you to more detailed information on the subject.  In answser to your questions, the main app would know the helper thread bombed in one of two ways: the helper sent it a message via intrathread communication, or I suspect the main app could monitor the state of the helper.  I don't know the exact call the main thread would use to kill the helper thread, but there has to be one.  I know that because when the main thread of a program is shut down it closes out the threads it spawned.  That tells me there has to be a terminate thread capability.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now