Why doesn't Windows XCOPY work when called through a Perl system call through psexec?

Question

I use psexec to run the Perl program on remote Windows computers. The program makes an xcopy system call. This works fine when executed directly (locally) on machines, but when remotely started via psexec, xcopy crashes with the following message:

Error creating file. Invalid function.

(Depending on the user, the message may instead be "Access denied.")

Note that $! gives the following diagnostics:

Bad file descriptor on syscall.pl. perl exited REMOTE with error code 9.

It doesn't seem to matter if xcopy is called via system () or backlinks.

I must indicate that the "from" folder is a dynamic view of ClearCase (M-drive).

Oddly enough, xcopy seems to work correctly when called directly from psexec.

Here are some other oddities:

• xcopy does not always fail. Some files just seem “damned”. The read-only attribute does not appear to be a factor.

• As soon as the copy completes successfully (for example, through Windows Explorer), the curse will be canceled, and this particular file will no longer cause xcopy errors.

• The problem is not related to the destination folder. After the curse is canceled, the file can be transferred to a new destination.

The following is part of the Perl script test. I used to narrow down the problem (folder names were generalized). Please note that for each test "my $ cmd" I commented on the previous one and added a comment to the state.

# ClearCase directory M:\STUFF\ABC contains ABC.tst, ABC.zip and several nonempty subfolders # Directory copy, D drive to D drive #my $cmd = "xcopy D:\\temp\\src D:\\temp\\dest /e /i /y"; # works # Directory copy, M drive to D drive #my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest /e /i /k /y"; # fails with "File creation error - Incorrect function" or "Access denied" # File copy (.tst), M drive to D drive (trailing backslash) #my $cmd = "xcopy M:\\STUFF\\ABC\\ABC.tst D:\\temp\\dest\\"; # works! # Directory copy, M drive to D drive (trailing backslash) #my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest\\ /e /i /k /y"; # copies the .tst file, but fails on the .zip (yes, the .tst file is now getting copied) # Directory copy, M drive to D drive (same as above but without trailing backslash) #my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest /e /i /k /y"; # copies the .tst file, but fails on the .zip # File copy (.zip), M drive to D drive #my $cmd = "xcopy M:\\STUFF\\ABC\\ABC.zip D:\\temp\\dest"; # fails # File copy (.zip), M drive to D drive (trailing backslash) #my $cmd = "xcopy M:\\STUFF\\ABC\\ABC.zip D:\\temp\\dest\\"; # fails # After manually (Windows Explorer) copying the .zip file to the dest folder and deleting it # Directory copy, M drive to D drive with /c (continue after failure) #my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest /c /i /e"; # copies the .tst and .zip file (!), but fails on all other files (folders were successfully created) # After manually copying the Folder1 folder to the dest folder and then deleting it #my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest /c /i /e"; # copies the .tst and .zip file and the contents of Folder1(!), but fails on all other files # Different dest: my $cmd = "xcopy M:\\STUFF\\ABC D:\\temp\\dest1 /c /i /e"; # Same results as immediately above print "Executing system command: $cmd ...\n"; system ($cmd); #print(`$cmd 2>&1`); #same 

Answer 1

I suggest that instead of using the xcopy command, you do the copying using Perl itself. There is a module File :: Copy :: Recursive , which is quite simple to use. It is not part of the standard Perl distribution, so you need to install it using cpan .

If you do not want to use non-native modules, you can try using File :: Find to find files in the directory, then combine this with File :: Copy .

Two examples found on Perl Monks . Using a combination and another using File::Copy::Recursive

Yes, this does not answer your question directly, but you should try to avoid using system commands whenever possible. When you interact with the system shell and the shell (especially when ClearCase hacks the file system), you may encounter many unintended interactions that may make something work in some situations, but not others.

To find out the problem you have with the system call, you have to assume that the error may be in ClearCase, cmd.exe shell, xcopy or Perl command. Without using the system command, you simplified your problem and actually speeded up the process many times.

Answer 2

Try redirecting INPUT from a null device to see if your xcopy is working. I don’t know why, I ran into this problem for a long time and somehow (perhaps through a web search) realized this.

It will look something like this:

xcopy /args $source $target <nul:

(Backticks around the whole team are not displayed)

Jke

Answer 3

File :: Copy :: Recursive can solve your problem.

This way you have a more controlled way to copy files. Can you translate this call into an eval block and apply some kind of retry logic there?

Maybe a "dummy update" on the problem file will help? Change the attribute / timestamp of the file or rename it to something else and rename it back ...

Answer 4

Have you tried system with a list of arguments?

 my @args= qw(M:\STUFF\ABC D:\temp\dest1 /c /i /e); warn "Executing 'xcopy @args' ...\n"; system xcopy => @args; 

Answer 5

If you look at how ClearCase controls read and write access for VOB and views , you will see that there is a difference between:

• reading directory contents ( rx required)
• reading a file in a directory (you only need " --x " in the directory + " r-- " in the file)

Thus, depending on which user is behind the xcopy startup process, you may have a problem reading / accessing certain directories / files.
And you need to make sure that using the CLEARCASE_PRIMARY_GROUP parameter matches the correct value (i.e., the group specified as the primary group of the voob or one of its secondary group) in order to access the VOB (but if its protection is weak enough, everyone can get access to it access anyway).

Everything that is used for dynamic viewing, and will only be used to update the view of the snapshot (as soon as the update is complete, you will receive files copied locally and which can be read by any process).