VB6 FileCopy destination lock failure leaves restored data unverified

Recommended Restore Mechanism

For a backup restore operation in VB6, the FileSystemObject (FSO) is the preferred mechanism over the intrinsic FileCopy statement. While neither method natively preserves full NTFS metadata or original timestamps, FSO provides a critical advantage: the Overwrite parameter. This allows the developer to explicitly define behavior when a destination file exists, and the COM-based error surfacing is generally more granular than the runtime errors triggered by FileCopy.

Implementation Strategy

To balance error visibility and reliability, use the following approach:

• Reference: Add a reference to Microsoft Scripting Runtime.
• Execution: Use FSO.CopyFile source, destination, True.
• Error Handling: Wrap the call in a Try...Catch equivalent (On Error GoTo) to specifically trap permission errors or destination locks.

Verifying Recovered Data

Since VB6 lacks an intrinsic hashing API, data integrity must be verified through a manual binary comparison. This ensures that the bytes written to the disk match the source exactly, bypassing the assumption that a "successful" copy operation implies semantic validity.

The most reliable method is to open both the source and destination files in binary mode and compare them in chunks:

' Simplified binary comparison logic
Open sourcePath For Binary Access Read As #1
Open destPath For Binary Access Read As #2

Do While Not EOF(1)
    Get #1, , buffer1
    Get #2, , buffer2
    If buffer1 <> buffer2 Then
        ' Handle mismatch
        Exit Do
    End If
Loop
Close #1
Close #2

Environmental Variations (VB6 vs. VBA)

The preferred restore path remains functionally the same, but the execution environment changes the risk profile. In a standalone VB6 executable, the application typically operates with the user's full filesystem permissions. In a VBA host (such as Excel or Access), the code may be subject to the host's security sandbox or "Trust Center" restrictions.

In VBA environments, you must verify that the host allows access to the target directory, as the host may trigger security warnings or block the FileSystemObject entirely if macros are restricted.

Diagnostic Requirement

To refine this recommendation, please specify if the target files are stored in protected system directories (e.g., C:\Program Files) or user-profile directories, as this determines whether the application requires administrative elevation regardless of the copy method used.