Copy Files action sometimes results in corrupt file
 

Hello-

I am using VBP 8.7. I have recently run into problems with build output files getting copied to a network share. The issue manifests itself in VBP as a failure to copy a file with the error "Access Denied". The build was trying to copy a file to a place where the previous build was. Each build overwrites the previous output.

In the past, I noticed there is some level of retry logic if a file can not be accessed that the Copy Files step employs. According to my help desk people, the issue was that the file about to be replaced was open by a user. Normally I would expect the copy command to enter its retry logic and eventually fail.

Instead what happened was the copy command proceeded and later failed. This left the file in a corrupt state and I couldn't delete or rename it. Its user rights were just gone.

My question is, how does VBP copy files? Is is the VB script:
' Copies a file
Sub vbld_CopyFile(SourceFile, DestFile, Overwrite)
' ensure that the target file is not read-only
If OverWrite Then vbld_MakeFileWriteable DestFile
' copy
vbld_FSO.GetFile(SourceFile).Copy DestFile, Overwrite
End Sub

What triggers the retry logic?

Do you have an suggestions as to server settings that can help eliminate this issue?

The Copy Files action calls the CopyFileEx Windows API to copy a file.

The action will retry a failed copy if 'Retries on failure' on the Errors tab is non-zero and the error result is one of:

ERROR_PATH_NOT_FOUND
ERROR_NOT_READY
ERROR_CRC
ERROR_SHARING_VIOLATION
ERROR_LOCK_VIOLATION
ERROR_NETWORK_BUSY
ERROR_UNEXP_NET_ERR
ERROR_SHARING_PAUSED
ERROR_REQ_NOT_ACCEP
ERROR_REDIR_PAUSED
ERROR_NET_WRITE_FAULT
ERROR_DRIVE_LOCKED
ERROR_BROKEN_PIPE
ERROR_OPEN_FAILED
ERROR_PATH_BUSY
ERROR_BUSY

or if 'Wait for share names to be defined...' on the Errors tab is checked and it is one of these errors:

ERROR_REM_NOT_LIST
ERROR_BAD_NETPATH
ERROR_DEV_NOT_EXIST
ERROR_NETNAME_DELETED
ERROR_BAD_NET_NAME

If the action did not retry a failed copy, the CopyFileEx API must have returned another error code.

I don't know what could have caused that sort of problem.

Similar problem
 

I've been encountering a very similar problem with the Copy Files action in VBP.

I am also using Visual Build Pro 8.7. I've been working on getting a new build system up and running. The primary hold up right now is the build is not reliable. VBP "hangs" on a fairly regular basis while building certain steps, most often those involving a file copy step whose destination is a folder on a network share.

The behavior I see is VBP starts to copy a file and then stops dead. Often an empty (0 bytes) file is created on the destination. "Retries on failure" option seems to make no difference (checked or not). "Wait for share names to be defined" is checked. Even the "Terminate action if not complete after" option seems to be ignored.

If the copy step has "*.*" and "copy subdirectories (recursive) for the source options, the operation sometimes stops on the first file attempted. But, not every time the build runs.

When I check a "stuck" build in this situation, VBP is still running and has open file handles on the source and destination files (confirmed by the SysInternals "Handle" utility).

The build system I'm working with is Windows 8.1 running under VMware. The VBP is invoked as a Windows scheduled task running under an admin user account.

Any thoughts or suggestions on how to get past this problem? This build machine has been languishing in "limbo" for some time largely due to this issue.

Thanks.

In v9, you could check Use Robocopy to copy files on the Remote tab to use Robocopy instead of CopyFileEx to copy files and see if it makes a difference.

http://www.kinook.com/VisBuildPro/Ma...obocopytab.htm

Otherwise, you could replace the Copy Files step with a Run Program action that calls xcopy or Robocopy.

https://technet.microsoft.com/en-us/.../cc733145.aspx

https://technet.microsoft.com/en-us/.../bb491035.aspx

Yes, I'm afraid I'm going to have to try something like that. Build is stuck again this morning in exactly the same place. Disappointing to say the least.