Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Functions

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

FileCopy Failing with 1008 Error

Keywords:  FileCopy SDK  1008

Question:

When I run the following command on a NT workstation, and the file already exists on the workstation, I get an error message and the WinBatch bombs out:
FileCopy("\\cosmos\share\winstall\nalinstl\nalexp\nalexp32.dll", "d:\winnt\system32", @FALSE)
I thought that this command would do an automatic overwrite without asking for user input?

Answer:

If the FileCopy fails, it generally means the file is in use and cannot be overwritten. This function will fail if the file you're trying to copy is opened by another application in read-deny mode. Check to see the status of the file first, with the FileExist function. If it returns a "2", that means the file is opened by another application.
```
if FileExist("mytarget.txt") == 2 then Message("Ah-ha!!", "File is Open in Read-Deny Mode")
```
The FileCopy will also fail if the target file is LOCKED. Try to manually delete the file first, and if you get, "Access Denied", then the file is locked by the system.
In this case, to do a delayed file move, you may want to investigate...
```
        IntControl(30...
```
in the WIL help file.
It has also been reported that sometimes FileCopy fails in the 32-bit version with an error "1008: File copy failed" when the target file:
- (a) is a UNC,
- (b) is on a network drive, AND
- (c) already exists
- (d) is read-only
- (e) has the hidden or system attribute set. Use FileAttrSet to first reset the bits, then FileCopy, or use the aFileCopy function in the Shell Operations Extender, which can do the copy regardless of the file attributes.
  Or use IntControl 5 to control whether system and hidden files or directories are seen and processed.
This may be due to file caching.
The solution is to do a FileDelete of the target file before performing the copy.
If the FileCopy operation works on a bunch of PCs in a network but fails on just 1 or 2, this *almost* always indicates a network card failure.
Swap out the network card on that PC.
To further diagnose a network card failure....
Find some whopping big file on the workstation. Excel.exe usually works. Using Explorer copy the file to the network server. Copy the file back to the PC with a different name. Compare source and destination files (fcomp?) (FileCompare) and see if they are the same or not.

Related Question:

I wonder if something has changed in the latest version (97d).
Before, I was able to copy a file onto itself. For example, I start the program MyProgram.exe on a workstation. If a newer version of the program exists on the server, the newer program was then copied in the same directory as the older program, hence overwriting the older program. It worked great for updates.
But now, this does not work. If I rename the program MyProgram.exe to something else and run it, the new version will copy just fine. (I'm using FALSE for overwrite warning).

Was there a change that does not allow FileCopy to overwrite a file that's in use or is open? If it was a "bug" in the previous version of the compiler it sure was a nice bug for us :-)

Answer:

The function FileCopy was always like this. You could not copy over a file that was in use and least in 32 bit Windows.

Now in WinBatch 16 bit land, if you were not running the *required* share.exe file in your autoexec.bat, then anything was possible)

Question (continued):

hmm, it is possible this happened with the 16 bit and I never really tried it out with the 32 bit version (I thought did). My program comes in both 16 and 32 bit versions. So now I need to come up with a different method for version control. Renaming itself probably won't work either.

Answer (continued):

I use a method whereby my compiled script COPIES itself to the temp directory, then runs the copy from the temp directory with some special parameter. That clues in the temp directory version to update the mail file it came from.

Microsoft Technote on FileCopy:

Here is a Microsoft technote, regarding a problem with the SDK function that our FileCopy command calls (in the 32-bit version only).

PSS ID Number: Q145935
Article last modified on 04-10-1996

4.00

WINDOWS

-------------------------------------------------------
The information in this article applies to:

- Microsoft Win32 Software Development Kit for Microsoft Windows 95 -------------------------------------------------------

SYMPTOMS
========

The CopyFile function fails and GetLastError returns ERROR_ACCESS_DENIED when you try to copy a read-only file to a core SMB server (such as a LAN Manager for UNIX server) or to a Netware server when the client computer uses real-mode network drivers. The destination file is created as a read-only file and is zero in length.

CAUSE
=====

This error message occurs because there is a mismatch between the way that the Windows 95 redirector accesses files and the way that these servers expect this access.

RESOLUTION
==========

Remove the read-only attribute before calling the CopyFile function to allow the file to be copied correctly. After the copy is complete, then the read-only attribute can be restored.

STATUS
======

Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

Additional reference words: 4.00 KBCategory: kbprg kbbuglist KBSubcategory: BseFileio

==============================================
Copyright Microsoft Corporation 1996.

Article ID:   W13063

Filename:   FileCopy Failure.txt

File Created: 2002:05:30:14:29:40

Last Updated: 2002:05:30:14:29:40