0

I have a situation, admittedly easily fixed, where I have a single one line piece of code as follows:-

My.Computer.FileSystem.MoveFile(f_source, f_dest, True)

The true is for the overwrite option.

I have an instance during bulk file moving where sometimes, just sometimes, a source file is left behind but the destination file is copied successfully.

There is error trapping surrounding it (VB.NET/try/catch) and yet no error is triggered. It only seems to happen during remote (VPN) access, the same operation on site hasn't manifested.

I suspect it is occurring during some kind of buffer filling since the move is to and from the remove drive which is a bit of a round Robin.

I have since added a check after the move to see if both files exist and to delete the source when they do. I can confirm that this has been triggered and it has, so far, cured my problem.

I am not using any background or threading operations. I am surprised that control is being handed back to my program with it unfinished and without an error. Is this a known problem?

I haven't tested the other movefile options and, of course, I could always just copy then delete so its no biggie but it did catch me out.

Tim F.
  • 268
  • 2
  • 8
  • Were you able to determine what might be causing it? You can use something like SysInternals tools to watch it and see if anything is working with the source file at the same time as your application. – Chris Fannin Apr 12 '16 at 21:09
  • To be honest the easy fix is an existence test afterwards so I have left it at that and, upon existence (of both files) I delete the source. There is something in what Chris Fannin wrote because I have spotted a retry on the delete and the error is the file is in use etc. but its not virus checking (I don't think). But it is so time critical that investigation would be a bit of a job. It doesn't happen within the server office (just VPN) and each uses UNC pathing. I find it very odd to have an OS call that doesn't do the job nor tell you via an error though! – Tim F. Apr 14 '16 at 11:33
  • I should add that this is happening out of office hours and the files are not available for general use at that stage so I can be sure no human has it open. I also note it happens midway through the batch process - never at the start and it seems to act like it is happening during some kind of buffering (bearing in mind the round robin of the process). So maybe the move isn't actually finished (or flagged finished) when it tries to issue its own delete. – Tim F. Apr 14 '16 at 11:38
  • That is very odd. It would be nice if it gave you a specific error to help with determining what's going on. It's a tedious job, but you can try using some of the SysInternals tools to monitor it and see what is accessing it, etc. – Chris Fannin Apr 14 '16 at 17:20

1 Answers1

2

I would assume that it is following the same rules at the System.IO.File.Move method. In the remarks for that, it says this:

If you try to move a file across disk volumes and that file is in use, the file is copied to the destination, but it is not deleted from the source.

There might be some type of latency in the I/O, especially if any type of file scanning (antivirus, etc) is going on.

Chris Fannin
  • 1,284
  • 1
  • 10
  • 16