Sign in to follow this  
Followers 0
Anteaus

FileCopy() backup issue - thoughts?

5 posts in this topic

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?

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

__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 by SmOke_N
Had to change IsString statement

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0