My app is transmitting files using a winsock TCP connection. I send the file in chunks (waiting for confirmation of each send before sending the next chunk to prevent overrunning the bandwidth). Before I put a file on the wire, as well as at the start of each chunk, I check to make sure the file exists and it is the same one I started with (i.e., filesize and filetimestamp are the same).
Code I am using to test the file is as follows:
If Dir(.qData(qpFilename)) = "" Then ' Check if File exists
' File is not present - Flag it as Invalid
blnFileInvalid = True
' File was found, check it's timestamp and size to see it is the current one
If FileLen(.qData(qpFilename)) = FSize And FileDateTime(.qData(qpFilename)) = FTime Then
blnFileInvalid = False
blnFileInvalid = True
My problem is that I occassionally get an Error 53 (File not found) thrown in the Dir() statement (I have no on error in the routine). I have also occassionally see the Error 53 in the FileLen() and FileDateTime() routines after the file existence has been successfully checked.
The file I am accessing/sending is on a network share. It is refreshed periodically by another routine running on the machine hosting the network share. I have a suspicion that the other machine/routine is active (the other machine is a 2-way system) and that the a new file is being swapped in when my code above is trying to access the file (and the "File not found" error is thrown because the file is locked while being written/renamed, not because it is missing).
1) Can anyone verify whether things like file locking (and/or other network share redirector access) can cause these Error 53's?
2) Will converting the code to use FileSystemObject constructs for the tests eliminate the problem?
3) I was thinking of leaving the file open for read (so that it will be locked out from being updated/replaced) during the 3.6 seconds (on average) that it takes to transmit (and let the other program deal with the "lock" issue. This will prevent the file from disappearing with each open I do to send another chunk. This still doesn't prevent the locking conflict (and error 53) from occurring on the first chunk to be sent. Can anyone suggest an alternative reason for the errors and a solution?