FileCopy() backup issue - thoughts?

[Anteaus]

Situation: Using FileCopy("source.dat","backup.dat",1) to make or update backups.

The issue arises when the source file is being held-open by another app, and cannot be copied. In this case you would expect the destination file to be left as-is... but what actually happens is that any existing backup of the file is deleted.

It seems that FileCopy's logic is to FIRST delete any existing destination file, THEN check to see if the source file is locked, and at that point to discover that the deleted file cannot be replaced. This leads to a loss of data from the backup, instead of its being updated.

I imagine the root of the problem might lie in Microsoft's file-handling DLL-calls, in which case little can be done to alter this behaviour.

One workaround would be to make a 'safe copy' such as a rename to 'filename.~' - but that would be extremely tedious, and would require double the disk-space to be available for any large file such as a .pst or .iso.

-Any thoughts on this?

[SmOke_N]

__FileCopy("source.dat","backup.dat",1)
If @error Then
    MsgBox(16, "Error", "Error = " & @error)
Else
    MsgBox(64, "Info", "Copied")
EndIf

Func __FileCopy($v_exe, $s_destination, $f_overwrite)
    If IsString($v_exe) Then
        Local $h_open = FileOpen($v_exe, 0) ; Sanity check
        If $h_open = -1 Then Return SetError(1, 0, 0)
        FileClose($h_open)
    EndIf
    Local $i_return = FileCopy($v_exe, $s_destination, $f_overwrite)
    If $i_return Then Return $i_return
    Return SetError(2, 0, 0)
EndFunc

Edited August 18, 2008 by SmOke_N
Had to change IsString statement

[Anteaus]

Thanks, that's an interesting angle on it. I'm not sure how much overhead there would be from opening each file before copying, but probably not too much.

[SmOke_N]

Thanks, that's an interesting angle on it. I'm not sure how much overhead there would be from opening each file before copying, but probably not too much.

FileCopy opens each anyway ... but the overhead shouldn't bother you if it doesn't delete your backups ... and you're right, it would be minimal in comparison.

[Anteaus]

A quick looping-test shows that opening/closing a 600MB pst takes around 10 microseconds on a 3GHz processor. Less than I'd expected, and totally negligible. I'm going to look-into the shadow-copy option, but this will be a good fallback to preserve the existing copy when/if that doesn't work.

Thanks.